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El universo 



Las imageries 

sinteticas 

son 

generadas 

por 

programas 

que 

describen 

objetos 3D. 



Las presentes paginas deben su existencia, sobre todo, al 
elevado numero de cartas recibidas donde los lectores 
reclamaban la inclusion de tal o cual apartado dentro de 
Rendermania. Evidentemente, era imposible contentar a todos 
dentro del limitado espacio disponible en las 5 paginas de la 
seccion y por ello PCmanfa ha tornado la decision de ampliar 

Rendermania, la cual, desde ahora, 
pasa a ser un suplemento. Como nos 
gustan las sorpresas no desvelaremos 
los apartados de que constara la 
nueva Rendermania, aunque, eso si, 
confiamos que sean del gusto de 
todos los afectados por el virus 
infografico. 

Ante todo, queremos agradecer al POV-Team la creation (y continua mejora desde hace anos) de lo que 

muchos pensamos que es el mejor trazador de rayos que pueda encontrarse para PC: El Persistence of Vision 

Raytracer (o sea POV). 

Tambien, queremos agradecer a Roberto Potenciano, Jose Gonzalez y Hector Iniesta que nosprestaron su 

ayuda con los bitmaps y dieron sus opiniones en las escenas. 

Finalmente, queremos agradecer los estimulos, consejos, notas, utilidades, escenas y animaciones de todos 

aquellos lectores que, a lo largo del tiempo, con sus cartas y e-mails, nos ban hecbo comprender que la 

Infografia es algo mas que la creation de imagen sintetica. Es tambieii algo que une a la gente. 
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de POV 3.0 



Por Jose Manuel Mufioz 



Este primer numero es espe- 
cial; ya que se dedica unica y 
exclusivamente a POV 3.0. Su 
contenido esta al alcance de 
cualquier novato, y se co- 
mentan caracteristicas de la 
nueva version 3.0, ademas 
de un pequeno proyecto re- 
alizado con dicha version, 
para beneficio de los pov- 
maniacos mas veteranos. 

Estas paginas han pasado 
por una larga evolucion. En 
principio se per 1=6 hacer un 
pequeno libro sobre POV, 
luego se decidio esperar al 
lanzamiento de la version 3.0 
y, finalmente, se tomo la de- 
cision de crear un suplemen- 
to de infografia "practica" cu- 
yo primer numero dedica- 
mos al que ha sido caballo 
de batalla de Rendermania 
durante tanto tiempo. 

En cuanto a este primer nu- 
mero, casi todas las image- 
nes se han creado usando 
una pequeha libreria que se 
adjunta en el CD: castlib 1 .8. 
Se trata de una libreria de for- 
mas para construir castillos, 
pueblos ; ciudades medie- 
vales con POV 3.0. Comen- 
zamos a desarrollar esta idea 
hace ya mucho -cuando los 
386 dominaban la tierra- pe- 
ro tuvo que abandonarse por 




falta de potencia del proce- 
sador, falta de memoria, falta 
de tiempo, y -sobre todo- 
por falta de ciertas sentencias 
en el lenguaje escenico de 
POV. Solo ahora, con todas 
estas carencias, parcial o to- 
talmente enmendadas, se ha 
podido dar a castlib un razo- 
nable grado de terminacion 
(al menos en el apartado del 
pueblo). De hecho, toda la 
libreria se reescribio varias 
veces bajo POV 2.2 para lue- 
go, tirarla al cubo y volverla a 
escribir bajo POV 3.0). Sin 
embargo, castlib esta incom- 
pleta aun. En el momento de 
escribir esto, muchas piezas 



necesarias para crear castillos 
aun estaban en fase de prue- 
ba. Por ello, se ha decidido 
extraer un fichero con el 
apartado que resultaba mas 
completo: el de las casas 
precisas para construir una 
pequeha ciudad medieval. 

(Y que ordenador se pre- 
cisa? Algunas escenas pue- 
den requerir un 486 con 16, 
o mejor 32 Megas de RAM. 
Esto no significa, no obstan- 
te, que un usuario provisto 
de un ordenador menos po- 
tente haya de renunciar a se- 
guir los ejemplos. Castlib 
puede ser recortada para 
crear escenas mas sencillas. 



Se entiende 
como 
"render" al 
proceso de 
generacion 
de la imagen. 
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Infografia y 



La idea en 
que se basa 
en Ray-tracing 
consiste en 
"lanzar" rayos 
desde la 
camara para 
cada pixel de 
la escena a 
calcular. 



Podemos definir el 
termino Infografia 
como la rama 
relativamente nueva 
de la informatica 
dedicada a la 
generacion de 
imageries por 
ordenador. 

Estas imageries "sinteticas" 
son generadas por progra- 
mas que utilizan datos que 
describen objetos tridi- 
mensionales para universos 
virtuales que solo existen en 
los ordenadores. Los resul- 
tados son moneda corrien- 
te para todos nosotros des- 
de hace ya afios: anuncios, 
animaciones y clips de gran 
realismo aparecen de ma- 
nera cotidiana en la televi- 



sion y el cine. Un ejemplo 
ya clasico, es la pelicula 
Terminator II, donde a la 
imagen real se le ahadia la 
generada por ordenador 
para el androide T1000. Ya 
antes se habian empleado 
efectos infograficos, pero 
quiza fue Terminator la peli- 
cula que mas hizo com- 
prender a todo el mundo 
las posibilidades de la info- 
grafia. Posibilidades que 
parecen ampliarse con ca- 
da nueva pelicu 
Mask, JumalifejP^iSt 
Twister, Independence Day 
y muchas mas. 

De todo esto se despren- 
de que una de las mayores 
ventajas de la infografia es 
la de permitirnos crear, con 
un realismo creciente, obje- 





tos que no existen en el 
mundo real, que estan en 
fase de diseno, o que nun- 
ca tendran una existencia fi- 
sica. Podriamos, por ejem- 
plo, (si tenemos los 
programas y equipos ade- 
cuados) simular un tornado, 
pasear por la Constantino- 
ple de tiempos del empe- 
rador Heraclio, recrear la vi- 
da de una hormiga, el 
comportamiento de un 
nuevo coche, el vuelo de 
Lit 
"evoTacion <X°uffS el 
etc. Aparte de nuestra ima- 
ginacion, el unico limite es- 
ta en la potencia de progra- 
mas y ordenadores y esta 
potencia aumenta de dia en 
dia, lo que esta permitien- 
do que la infografia tenga 
una presencia cada vez ma- 
yor en un campo tan popu- 
lar como el de los videojue- 
gos de PC («Doom», «Duke 
Nukem», «Quake», etc.). Por 
otro lado, otra de las razo- 
nes del creciente interes de 
la infografia es que cual- 
quiera tiene la posibilidad 
de llegar a hacer cosas inte- 
resantes. En principio basta 
con disponer del ordena- 
dor mas difundido del pla- 
neta: el PC. 

Diversos tipos de 
render 

Existen muchos programas 
generadores de imagenes 
fotorealistas para todo tipo 
de platafomas y tambien 
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trazado de rayos 




una gran cantidad de meto- 
dos o algoritmos distintos 
para generar imagenes por 
ordenador. Ademas, la im- 
plementation de un mismo 
metodo puede variar de un 
programa a otro, ya que los 
programadores pueden 
combinar diversos algorit- 
mos de sombreado, oculta- 
cion de superficies, trata- 
miento de color, etc., para 
construir el motor 3D del 
programa. 

(Llamamos motor 3D a la 
parte de codigo del pro- 
grama encargada del pro- 
ceso de Render. En cuanto 

proceso de Render en si, 
e^gjjfende como tal a I 
proc%s^raeSsneraci6n de 
la imagen. w*>K3^dfelyjw 
3D Studio, Imagine ©Seua/'? 
quier otro programa de este 
tipo, decimos que se esta 
efectuandoel Render cuan- 
do el programa esta calcu- 
lando la escena, aunque es- 
ta no sea visible en 
pantalla). 

El trazado de rayos o Ray- 
tracing es, simplemente, 
uno de los muchos meto- 
dos existentes para la gene- 
racion de imagenes foto- 
realistas. Programas como 
POV, Polyray e Imagine uti- 
lizan el trazado de rayos 
mientras que otros como 
3D Studio no lo emplean. El 
trazado de rayos fue idea- 
do, en principio, como un 
algoritmo de ocultacion de 
superficies y solo posterior- 



mente se convirtio en un 
metodo de sombreado. 

(Un algoritmo es un meto- 
do para resolver un proble- 
ma dado. La ocultacion de 
superficies es uno de los 
problemas basicos a los 
que debe enfrentarse cual- 
quier programador grafico. 
Se refiere al proceso por el 
que se decide que superfi- 
cies quedan mas cerca del 
observador, a fin de repre- 
sentarlas en el orden co- 
rrecto. 

Un metodo de sombrea- 
do es cualquier algoritmo 
que emplee uno de los mu- 
chos modelos matematicos 
de iluminacion existentes 
para sombrear -dibujar-, de 
manera mas o menos realis 




Ray-Tracing 

La idea en que se basa el 
Ray-tracing consiste en "lan- 
zar" rayos desde la camara 
u observador para cada pi- 
xel de la escena a calcular. 
Estos rayos del "observa- 
dor", al viajar por el universo 
virtual, pueden chocar o no 
con un objeto. Si este cho- 
que no se produce, el pixel 
toma el color del fondo. 

En caso contrario, el color 
del pixel se determinara 
dependiendo del color 
propio de la superficie, el 
color de las fuentes que in- 
cidan sobre el, etc. 

Debido a esto, este me- 
todo es llamado tambien 
"de seguimientQ-de%yds".' 
En principi<Spd<$Efe supo- 
nerse que to logico seria 




Cuanto 
mayor sea la 
complejidad 
de la escena 
mayor sera el 
tlempo que 
precisara el 
PC para 
completarla. 
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que el prosrama efectuase 
el sesuimiento de los rayos 
desde las fuentes de luz de 
que parten estos, hasta lie- 
gar a! observador. Pero esto 
no es practico: habria que 
seguir.-muchisimos rayos 
in levisimas variactones eri 
ang u I o de- fa n za rm'e nto , 
para, gara'ntizar„una ilunrvin'a- 
"cion adeeaada para'fas slk' 
Sficies. Adefnas, yn-'por- 
jsntaj'e muy ejevaclo deJds 
rayos,Jarrzados ncu^SultariacK' 
"utiles jglo-eSTno llegarfan al , 
fpectadoj>Pof el lo estos 
iJatfiaremi 



en |a escenaypara/clec/dir s/ 
dichas fuentes inciden sc 
bre,el punto visible. Ta 
bien, si la superfjcie afcan^ 
zada- 1 es/reflactanie, se 
lanzaraxin rayo en/fa di/ec- 
Tion/de reflexiori pa/a de 
terfnina/el cotor a pefleja 

roeeso. 
curs 
cak 

lentarse mychas/ 
; al lorecesO/descriJ 
■ defecto,^trazacio 
tieneren cuenta la 



' Fre? 
»l ui 
ob/i 



ijemahte, 

estos AieW 
usuarioA un/raba 1 



3li! 

yos. Usa 
jfe Ra 
4leca 



i\ pa/a igwalar/el 

toazado da ra- 

un prosrama 

Ins, 



proceso^s re^ 
lie 




5esde 



eh 



icamir 



7ersoal< 



real. 
rayo^pjiflcTpal 
choca ] 

de un objejpitay'que deci 
— direTcolor enese-parvto. 

HoTse lanzan desde 
ahi otros rayos -uno para 
cada fuente de luz definida 



3e los^atfjetoylas refl^xio 
, sornbfas, eto-Cebicjefi 
todp-el^to, las^magepies ge- 
ineradas^con ternicas de 
-tracipg^ienen un nivel 
myydevado de realismo. 
Otros metodos de som- 
breado consiguen generar 
imagenes en menos tiempo 
pero a cambio de un menor 
"foto-realismo". 



: Igis ob/etos, 
de 
superficies, oolocar la 
mos un 
I que 
;e con una 
la similar 
jn eKTiundo real, 
^laturalmente no todo es 
'de color de rosa. El modelo 
de iluminacion del trazado 
de rayos funciona muy bien 
en casi todos los aspectos 
salvo en el de la luz difusa. 
i,y que es la luz difusa? 
Bien: todos los objetos ffsi- 
cos del mundo real reflejan 
la luz que reciben (salvo los 
cuerpos celestes llamados 
agujeros negros y los dispo- 




siiivos de camuflaje de las 
\izs de presa Klingon, en 
Star Trek). Como la mayoria 
' de las superficies del mun- 
do real son irregulares en 
mayor o menor medida, los 
rayos reflejados no abando- 
nan estas superficies con el 
mismo angulo de inciden- 
cia con que llegaron a ella. 
Es esta luz difusa la que ilu- 
mina a los objetos sobre los 
que no caen directamente 
los rayos de un foco de luz. 
Tambien, es esta luz la que 
suaviza los bordes de las 
sombras. (Consideremos, 
por ejemplo, el aspecto de 
un cuarto oscuro en el que 
se filtran los rayos de luz a 
traves de una persiana. Sin 
luz difusa no podriamos 
percibir a los muebles en 
penumbra). Para simular la 
luz difusa, los trazadores de 
rayos emplean un truco lla- 
mado iluminacion ambien- 
tal, el cual, desgraciada- 
mente, no se acerca 
demasiado a la realidad. 

Otra limitacion importan- 
te del modelo luminoso de 
los trazadores de rayos es 
que las fuentes de luz son 
puntos infinitamente pe- 
quenos. Esto causa proble- 
mas con las sombras ya 
que, al no calcularse la luz 
difusa, las sombras tienen 
unos bordes excesivamen- 
te nitidos. (Esto puede en- 
mendarse, por ejemplo, 
empleando areas de luz). 
Otros modelos luminosos 
que solucionan estas limita- 
ciones se basan en la "ra- 
diosidad". Desgraciada- 
mente la radiosidad, a su 
vez, tiene problemas con 
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las reflexiones especulares 
y requiere un tiempo de 
calculo considerablemente 
superior incluso al precisa- 
do por el Ray-tracins. Si lo 
mencionamos es porque 
POV, a partir de la version 
3.0, incorpora la radiosidad 
comoopcion. 

Asi, en resumen, la canti- 
dad total de calculos para 
crear una imasen es muy 
grande y cuanto mayor sea 
la complejidad de la esce- 
na mayor sera el tiempo 
que precisara el ordenador 
para completarla. El proce- 
so puede durar minutos, ho- 
ras, dias, o semanas enteras 
dependiendotambien de la 
potencia del ordenador, o 
de la del propio Ray-tracing. 
Por esta razon, lo que aca- 
bamos de explicar sobre el 
trazado de rayos nos sera 
util mas tarde, cuando estu- 
diemos los diversos meto- 
dos existentes para ahorrar 
tiempo de calculo. 

tQue tiene POV de 
especial? 

Persistence of Vision Raytra- 
cer, abreviadamente llama- 
do Povray o POV, es el 
nombre del trazador de ra- 
yos sobre el que trata este 
suplemento. 

Persistence of Vision Team 
(o pov-team) es tambien el 
nombre del grupo de pro- 
gramadores que nacio con 
la finalidad de crear el Ray- 
tracer POV. Hace ya unos 
cuantos anos existfan otros 
Ray-tracers para PC, recor- 
vertidos desde amiga en su 
mayor parte. Pero, insatisfe- 
cho con estos programas, el 



grupo formado por Drew 
Wells decidio crear un nue- 
vo Ray-tracer basado en el 
trazador de rayos DKBTrace 
de David Buck y Aaron Co- 
llins (los cuales se sumaron 
al proyecto). Con este fin se 
establecio el cuartel general 
del grupo en el foro 
GRAPHDEV de CompuSer- 
ve y, desde entonces, se 
han publicadovariasversio- 
nes de POV con un exito 
creciente. 

Actualmente, hay versio- 
nes de POV que funcionan 
bajo MS-DOS, Windows 
3.x, 95 y NT, Linux, Apple 
Macintosh 68k y Power PC, 
Amiga, UNIX y otras plata- 
formas. La ultima version de 
POV la podeis encontrar en 
su direccion oficial via Web 
en http://www.povray.org, 
o via ftp, en ftp.povray.org. 
Pero tanto el programa co- 
mo muchas de las utilida- 
des que se han creado para 



el se pueden encontrar en 
muchas direcciones mas, 
portodoel mundo. 

iCual es la razon de este 
exito? En primer lugar, por , 
supuesto, la increible cali- 
dad del programa. Los 
miembros del pov-team lie- 
van ahos trabajando ininte- 
rrumpidamente para que 
POV no se quede estanca- 
do, como ha sucedido con 
otros trazadores de rayos 
que han acabado desapa- 
reciendo. En parte para ga- 
rantizar esta calidad, el 
pov-team es un grupo 
abierto, donde, segiin pa- 
rece, pueden entrar nuevos 
miembros, si estos tienen 
algo interesante que aportar 
al proyecto (esto fue lo que 
sucedio con Dieter Bayer y 
su FTpov). Este factor que- 
da reforzado por el hecho 
de que los fuentes de POV 
son de libre distribucion. 
Cualquier programador 



puede compilar su propia 
version de POV, e incluso 
incorporar sus propios 
cambios, si tiene los cono- 
cimientos y la capacidad 
necesarias (aunque debe 
indicar que se trata de una 
version no oficial\ 

Las caracteristicas'del pro- 
grama que, practicamente 
desde el principio, ofrecia 
una excelente relacion tiem- 
po/calidad, atrajeron a mu- 
chos artistas que comenza- 
ron a publicar escenas 
creadas con POV. Esto a su 
vez estimulo la creacion de 
utilidades especificas y la 
adaptacion de otras para 
trabajar con POV. 

Por ultimo, hay que citar 
un pequeho detalle: POV 
es de libre uso. No hay que 
pagar un centimo por su 
empleo y esto, junto a su 
potencia y los factores an- 
tes citados, ha creado la 
bola de nieve que ha hecho 







de POV el trazador de ra- 
yos mas popular del mun- 
do PC. Es porestas razones 
que POV ha sido el caballo 
de batalla fundamental del 
suplemento Rendermania y 
por esta misma razon se le 
dedican estas paginas. 

El trabajo con POV 

Para crear una escena con 
cualquier software de ge- 
neracion de imagen de sin- 
tesis, ya empleamos traza- 
do de rayos o cualquier 
otro metodo, habremos de 
suministrar al programa una 
descripcion de la escena a 
renderizar en un formato 
comprensible. Habra que 
indicar la posicion espacial, 
forma y propiedades de los 
objetos, la colocacion y 
orientacion de la camara y 
las fuentes de luz, y muchos 
otros detalles mas. El fiche- 
ro con la descripcion nece- 
saria puede crearse, basica- 
mente, de dos maneras 



distintas: usando un progra- 
ma de modelado o bien es- 
cribiendo directamente el 
texto con la descripcion, 
empleando lo que se llama 
un lenguaje escenico. 

El primer sistema es el 
que emplean paquetes co- 
mo 3D Studio, Imagine, Ca- 
ligari TrueSpace, Topas y 
otros. En cada uno de estos 
productos, la forma, el sis- 
tema de trabajo, y las op- 
ciones de cada modelador 
son diferentes, pero pode- 
mos destacar algunas carac- 
teristicas comunes: en todo 
programa de modelado 
existen una serie de opcio- 
nes para construir objetos 
simples como esferas, cu- 
bos, conos, cilindros, etc., 
y tambien formas mas com- 
plejas empleando metodos 
de extrusion, de revolucion 
y otros. Luego, pueden rea- 
lizarse diversas operaciones 
sobre estos objetos inicia- 
les y obtener objetos aun 



mas complejos. Despues, 
podemos colocar camara y 
luces, y ordenar la renderi- 
zacion de la escena. Mu- 
chas de estas operaciones 
pueden realizarse tambien 
con los lenguajes escenicos 
pero el empleo de un mo- 
delador es, en general, si 
esta bien disefiado, mas ra- 
pidoe intuitivo. 

Veamos porque: en un 
modelador podemos acce- 
der a las distintas opciones 
empleando sistemas de 
ventanas o iconos, sin tener 
que escribir nada. Los obje- 
tos suelen visualizarse como 
mallas de hilos en una o mas 
ventanas de trabajo con dis- 
tintas vistas y, lo mas impor- 
tante, a I ordenar una trans- 
formacion cualquiera sobre 
un objeto; un desplaza- 
miento, una escalacion, una 
operacion CSG, etc., vere- 
mos el resultado en las ven- 
tanas de trabajo, sin necesi- 
dad de ordenar un render. 




En POV, y en otros pro- 
gramas que carecen de mo- 
delador, el sistema es total- 
mente distinto. Usando un 
editor de texto cualquiera 
escribiremos un fichero 
que, empleando las senten- 
cias permitidas por el len- 
guaje escenico, describira 
la escena. Luego, invocan- 
do al programa, le daremos 
como entrada el fichero es- 
cenico escrito y le ordena- 
remos su proceso. En caso 
de que haya algun error de 
sintaxis en alguna sentencia 
del texto de entrada, el 
programa no mostrara nada 
y se limitara a indicar el 
punto del error en el fichero 
de texto. Entonces, debe- 
remos corregir el error des- 
de el editor de texto y vol- 
veremos a ordenar el 
render. Otra posibilidad es 
que el programa renderice 
la escena pero los resulta- 
dos no sean los esperados, 
al haber cometido algun 
error logico o espacial en la 
colocacion de los objetos 
o en las operaciones entre 
estos. Cuando esto suceda, 
deberemos volver de nue- 
vo al editor de texto para 
arreglar el problema. Este 
sistema es, como se ve, 
identico al que sigue un 
programador para compilar 
su trabajo y la mayor pega 
esta en que los resultados 
de las operaciones no se vi- 
sualizan "en tiempo real", 
ccuna^jpjnjTio d e I a d o r. 

bio necesitaremos ordenar 
un render). 

Pero no todas las ventajas 
estan del lado de los mo- 
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deladores. En primer lusar, 
anurias de las sentencias del 
lensuaje escenico de POV 
nos permitiran leery emplear 
objetos creados con mode- 
ladores, con lo que, si dis- 
ponents de alguno, podre- 
mos aprovechar sus ventajas. 
Por otro lado, las sentencias 
de POV crean objetos cuya 
forma viene definida por for- 
mulas y no por poligonos, 
como suele ser el caso de 
todos los modeladores. Es- 
to implica dos cosas: la pri- 
mera, que los ficheros crea- 
dos con un lenguaje 
escenico suelen ocupar mu- 
cho menos espacio que los 
archivos generados por los 
^^Nnnodeladores (incluso en el 
**^~$&g<le que los modelado- 



res realicen la grabacion en 
aigun formato comprimido 
propio). Pensemos, por 
ejemplo, en una esfera. Su 
definicion tan solo requerira 
unas pocas palabras con un 
lenguaje escenico, pero 
cualquier modelador habra 
de almacenar una lista de 
vertices y poligonos. 

Otro efecto de esto es 
que una esfera definida por 
una formula es perfecta: por 
mucho que acerquemos la 
camara a ella, seguiremos 
apreciando correctamente 
su esfericidad. En cambio, 
una esfera definida por poli- 
gonos tan solo aparentara 
serlo si el numero de poligo- 
nos empleado es lo bastante 
alto y la camara no la enfoca 



a corta distancia. Finalmente, 
hay que anadir que la nueva 
version de POV incluye im- 
portantes mejoras en el len- 
guaje escenico. Gracias a 
ellas, podremos conseguir 
escenas que impresionaran a 
cualquier usuario de un pro- 
grama de modelado (a me- 
nos, claro esta, que dispon- 
ga de un paquete cuyo 
coste sobrepase las 400.000 
mil pesetas o mas). En todo 
caso, para quienes no lle- 
guen a acostumbrarse al len- 
guaje escenico, la populari- 
dad de POV ha propiciado 
la aparicion de diversos mo- 
deladores que generan fi- 
cheros de escena directa- 



mente digeribles por POV. 

Estos modeladores repre- te respecto. 



sentan los objetos de mane- 
ra "poligonal" pero graban 
las escenas empleando el 
lenguaje escenico de POV. 
Esto origina una serie de pro- 
blemas que parecen unicos 
de estas utilidades: no se re- 
presentan bien las operacio- 
nes CSG, no pueden leerse 
archivos de POV, etc. 

(Por ello, preferimos em- 
plear solo el lenguaje esceni- 
co. La libreria Castlib ha sido 
creada "manualmente", sin 
emplear ningun modelador). 

Ademas, como estos 
modeladores estan estre- 
chamente relacionados 
con el lenguaje de POVes 
recomendable aprender 
todo 16 que se pueda a es- 
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El uso de POV 




Las imageries 
se crean 
por defecto 
con +Q9. 



En las siguientes Ifneas 
vamos a analizar los 
pasos para instalar la 
nueva version de POV. 
La version cuya 
instalacion vamos a 
comentar es la de PC 
bajo MS-DOS ya que es 
la mas popular. Esta 
version puede 
ejecutarse tambien 
desde una caja-MS 
DOS de Windows. 
(Temas que se trataron 
en el numero 47 de 
PCmania, con motivo 
de la publicacion de 
POV, pero tambien nos 
parece adecuado 
insertarlosaqui). 

POV viene comprimido en 
un fichero llamado Povms- 
dos.zip. Deberemos guar- 



dar este fichero en un di- 
rectorio temporal y, desde 
alii, procederemos a des- 
comprimirlo usando el pro- 
grama Pkunzip. Hecho esto, 
aparecera ante nosotros el 
verdadero paquete de ins- 
talacion: lnstall.exe. Este 
programa requiere 600 Kby- 
tes de memoria convencio- 
nal y es autoexplicativo 
(aunque en ingles, claro). Al 
ejecutarlo, el programa so- 
licitara que especifiquemos 
un disco y un directorio 
donde guardar el paquete a 
instalar. Hecho esto, se pro- 
cedera a realizar la instala- 
cion, creandose una serie 
de subdirectories dentro 
del directorio que hayamos 
indicado al programa de 
instalacion. Al finalizar el 
proceso, aparece un texto 




del coordinador del Pov- 
team, explicando algunos 
detalles sobre la version. 

Town.inc 

Con este suplemento inclui- 
mos la version 1 .8 de castlib 
compuesta por un unico fi- 
chero llamado town.inc. 
Ademas, se incluyen los fi- 
cheros de escena llamados 
escenaxx.pov, los ejemplos 
llamados ejempxx y los fi- 
cheros bat. 

(Las xx indican el numero 
de escena o ejemplo). Lo 
ideal es crear un nuevo sub- 
directorio -al que desde 
ahora nos referiremos por el 
nombre: media- dentro del 
directorio de POV. Sera en 
este subdirectorio donde 
ejecutemos todos los ejem- 
plos de uso de la libreria. 

Ejecutar POV bajo 
DOS y Windows 

Como sucedia en versiones 
anteriores, el fichero autoe- 
xec.bat debera indicar un 
path a povray.exe si desea- 
mos ejecutar el programa 
desde cualquier directorio. 
Tambien, deberemos espe- 
cificar el path a los nuevos 
ficheros include usando la 
orden "L" de la linea de co- 
mandos. Una vez impartida 
la orden a POV, el programa 
funcionara igual que siem- 
pre, aunque con algunos 
pequehos cambios. En pri- 
mer lugar, cuando la imagen 
termine de generarse, POV 
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no saldra al DOS, sino quit 
nos permitira observar disA 
tintas pantallas informativas , 
con estadisticas, opciones 
usadas en la generacion, e 
informacion del prosrama. 
Podremos cambiar de una 
pantalla informativa a otra, 
usando las teclas de flecha 
y salir de POV con Return. 
En caso de fallo, POV nos 
dara la posibilidad de exa- 
minar dos pantallas adicio- 
nales "Error" y "Debug". 

Por otro lado, como se ha 
dicho antes, la version MS- 
DOS de POV puede funcio- 
nar desde una caja DOS de 
Windows. Teoricamente, 
podemos lanzar varios ren- 
ders simultaneamente em- 
pleando varias cajas pero, 
como podeis imaginar, esto 
no es demasiado practico. 
Por un lado, una unica CPU 
debera repartir su tiempo 
entre dos o mas procesos 
de render, con lo cual no 
ganaremos tiempo con res- 
pecto a una lista de renders 
secuenciales (ordenados 
desde un fichero bat). Otro 
posible inconveniente esta 
en la visualizacion. 

Aunque la generacion de 
la imagen sea correcta, es 
posible que haya fallos de 
visualizacion al cambiar de 
una"caja-Dos"aotra. 

Documentation 

POV siempre ha contado 
con una excelente docu- 
mentacion en ingles que, 
en la nueva version, ha sido 
ampliada y apoyada por la 
inclusion del programa Pov- 
help, con el que podremos 
acceder a cualquier tema, 




desplazandonos con las te- 
clas de flecha sobre los ti- 
tulos y pulsando Enter para 
acceder a los temas. 

Tambien, para quienes lo 
prefieran asi, resulta posible 
obtener un fichero ASCII 
con el manual, usando la si- 
guiente linea: 

phe2txt -ipovhelp.phe -f 

Ficheros .inc y 
escenas de ejemplo 

Otra valiosa fuente de infor- 
macion para el povmaniaco 
novato esta en los muchos 
ejemplos que incluye POV. 
Estos ejemplos son ficheros 
ASCII con una descripcion 
de una escena tridimensio- 
nal formulada usando las 
sentencias permitidas por 
el lenguaje escenico de 
POV, como antes se dijo. 
Los archivos de POV, usan 
siempre las extensiones 
.povo .inc para indicarque 
son ficheros escenicos de 
este Ray-tracer. Un escena 



o 
muchos de estoiT'atchivos^ 
Usualmente en cada pr 
yecto solo habra un archivo 
con la extension .pov. Este 
fichero sera el principal y el 
que cargara a los archivos 
.inc con ordenes include. 
Como ya supondreis, cual- 
quier proyecto descrito 
con estos archivos debe 
definir una camara que "re- 
trate" la escena, luces que 
la iluminen, y objetos diver- 
sos. Si alguno de estos tres 
tipos de elementos no se 
incluye en el proyecto, el 
resultado sera una pantalla 
en negro. 

En su version 3.0, el usua- 
rio puede consultar diver- 
sos tipos de ejemplos: en 
el directorio Pov3demo ve- 
remos varios subdirecto- 
ries, cada uno de los cuales 
incluye varios ejemplos del 
tema a que hace referenda 
el nombre del subdirecto- 
rio: atmos (efectos atmosfe- 
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ricos), camera (ejemph 
usp- de la eamara), objects/ 7 
''tusodelosqbj'etos/slmpj^'s 
que pueden crearse/con/ 
POV)',"light,s-{tuces>;etc. 

La ntieva version tanlbien 
tonserya-fbs ejerfiplosxde 

, -versTones apt€fiores„et1 el d> 
regtoribpovscn^stos ^jem- 
plos ?stan divididbs enya^ 
fos subdjracforios^segun sg 

.-GorTTpTej ida^Por ultirperfen 
eLcUfectbrio texsafnps 
dremos-gerierar escartas de^ 

'cficadas ajaKmam<xJes\\- 

.-brerTa'de textufafcle Pf 
Lajnaydrfa de ejjlas-texturas. 
han sicjo-erelfdas potarfistas 
He POV (miiehSsson idg 
iTier) y estai>d5sif icada 
irectoriosj-^bods 
(madexas)rTnetals (meiatesl 
stones (giedfasXskies i 
sTyglassesicristSles). To- 
Ssmagnit 
haruside^Cteadas usando 
sentencias del lenguaje de 
POV y el lector puede exa- 
minar las definiciones en el 
directorio llamado include. 
La manera ideal de estu- 
diar el lenguaje escenico es 
realizar experimentos con 
los ficheros del directorio 
pov3demo, ya que son los 
mas recientes. En particular 
con los ficheros de objects, 
camera y lights. Podremos 
probar las brdenes de la li- 
nea de comandos o probar 
cambios en las sentencias 
de los ficheros y aprender 
de ello. (Tambien conviene 
hacgLOOc^s de los ficheros 

cheros de ejemplo puederr 
usarse como punto de parti- 
da para crear nuestras pro- 
pias escenas. 
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que 
Los^bmandbs cMa lined de 

ifdengs pupden ser d 
p^stos erf cualquier orcien 
y var>precedidos cle'lo; 

>los yo-. Poprtor 
raj^dsimbedo + sjjele a< 
el pMafnetroxfue league 
lo dgsactiva, 
lando setsta tnabajan 
en up-broyepto pueele ser 

:il renclefizar es<renas dis- 
i o ernplear diversos pa- 
ramptrOs. Por esta razbn, y 

>ara no tener que estar tras- 
teando continuamente con 
las lineas de brdenes, pue- 
den usarse diversas alternati- 
ves. La primera es tener uno 
o mas ficheros bat para invo- 
car a POV con los comandos 
y brdenes pertinentes. 

Otra posibilidad es crear 
ficheros ini, donde escribi- 
remos una lista de opcio- 
nes por defecto. Los fiche- 
ros ini admiten los mismos 
comandos que las lineas de 
brdenes y podemos invo- 
carlos desde la linea de br- 
denes, y mezclar su uso 
con comandos de linea. 
Veamos por ejemplo: 
POVRAY RES800 +lprue- 
ba.pov +oprueba.tga. 
—La primera palabra de la 
iKgaJj^Upmbre del eje- 
cutabTe ^f^rejy. Sigue el 
nombre del ntRfe|b\jni, y 
luego dos coman< 




+Hn Resolucion vertical de la imagen a generar. N es la altura en pixels. 
+Wn Resolucion horizontal de la imagen a generar. N es la anchura en pi- 
xels. 

+D Activa la visualization de la escena mientras se va generando. 
-D La desactiva. 

+Dn Activa la visualizacion en el modo grafico numero n. 
Lista de tarjetas soportadas por +D +D0 Autodeteccion de (S)VGA type 
(puesta por defecto) +D1 Standard VGA 320x200 +D2 Standard VGA 360 
x 480 +D3 Tseng Labs 3000 SVGA 640x480 +D4 Tseng Labs 4000 SVGA 
+D5 AT&T VDC600 SVGA 640x400 +D6 Oak Technologies SVGA 640x480 
+D7 Video 7 SVGA 640x480 +D8 Video 7 Vega (Cirrus) VGA 360x480 +D9 
Paradise SVGA 640x480 +DA Ahead Systems Ver. A SVGA 640x480 +DB 
Ahead Systems Ver. B SVGA 640x480 +DC Chips & Technologies SVGA 
640x480 +DD ATI SGVA 640x480 +DE Everex SVGA 640x480 +DF Trident 
SVGA 640x480 +DG VESA Standard SVGA Adapter +DH ATI XL display 
card +DI Diamond Computer Systems SpeedSTAR 24X +Dnp Idem, que 
orden anterior pero usando el modo de paleta numero p. 
Lista de tipos de paleta soportados +D?3 Paleta 332 (la usada por defec- 
to). Esta compuesta por 256 colores con 3 bits para el componente rojo, 3 
para el verde y 2 para el azul. 

+D?0 Paleta de 256 colores que usa el sistema de color HSV. 
+D?G Usa una paleta de 64 tonalidades de gris. 
+D?H Opcion HiColor (32000 colores con 5 bits por componente). 
+D?T Opcion Truecolor (color real). 24 bits bajo Vesa. 
Cuando solo nos interesa visualizar una pequenazona de la imagen (por- 
que solo se esperan cambios en ella), utilizamos los siguientes 4 coman- 
dos: +SCn La columna n sera la inicial del recuadro parcial a renderizar. 
+ECn Para el mismo recuadro, n sera la columna final. 
+SRn Columna inicial del recuadro. 
+ERn Columna final del recuadro. 

+X Permite interrumpir la generation de la imagen pulsando una tecla. 
+C Permite reanudar el calculo de una imagen interrumpida con +X. 
+P Al finalizar el calculo de la imagen, POV esperara a que se pulse una te- 
cla para salir. Usamos +p para ver la imagen cuando ha concluido el cal- 
culo. +P se usa junto a +D. 

+V Cuando, por la razon que sea, decidimos desconectar el display de la 
imagen (-D), puede ser conveniente saber que linea esta calculando POV 
en cada momento. Con +V activaremos esto. En caso de que se active la 
visualizacion (+D), deberemos usar-V 

tlname Junto a +l, se indica el nombre del fichero escenico de entrada. 
+0name Junto a +0, se indica el nombre del archivo grafico de salida. 
+Lpath Por defecto POV solo examina el directorio en curso para buscar 
los ficheros include que solicita el fichero .pov que se va a calcular. Con la 
opcion +L podremos indicar una ruta a un directorio donde hayamos al- 
macenado ficheros de inclusion. Es posible emplear varias ordenes +L 
+Qx El valor x indica la calidad del render. Valores de o 1 usaran solo ilu- 
minacion ambiental, 2 y 3 usaran luz difusa, 4 renderiza sombras y 5 apn- 
ea luces zonales, 6 y 7 calculan texturas, el valor 8 calculara rayos refleja- 
dos, refractados y transmitidos y a partir de 9 se calcularan halos. El valor 
por defecto es 9. 

+QR Se calcula la radiosidad de la escena. 
+Bx Normalmente, cada vez que concluye el calculo de una linea, POV la 
graba en el archivo grafico de salida. Si queremos minimizar el numero de 
grabaciones emplearemos este comando cuyo valor x es el numero de 
Kbytes reservados para el buffer de grabacion. 
+A Activa el antialias al valor por defecto (0.3). El antialias se emplea para 
suavizar la apariencia "dentada" que tienen en la escena las lineas diago- 
nales. Por defecto el antialias esta desactivado (-A). 
+Ax Cambia el valor para el antialising. 

+Kx Usada para pasar un valor x en flotante a la variable clock que es em- 
pleada por POV para hacer animaciones. 
+MVx Emplea la sintaxis de la version x de POV (para ejecutar escenas 
antiguas). 

+SPx Usa un efecto de mosaico que nos permite hacernos una idea del 
aspecto general de la imagen antes de que esta se calcule por entero. Si 
por ejemplo x=16, se calcularan y visualizaran puntos de 16x16 pixels. 
Luego la representacidn pasara a puntos de 8x8 pixels, y asi hasta llegar al 
calculo pixel a pixel. 






nea de ordenes que indi- 
can, primero, el nombre del 
fichero escenico a procesar 
y, despues, el nombre del 
archivo grafico a producir. 
En los ficheros ini las opcio- 
nes pueden especificarse 
tambien con ciertas pala- 
bras en vez de con coman- 
dos de linea pero, al ser un 
tema algo redundante, no 
las trataremos en esta oca- 
sion. Nos limitaremos a los 
comandos de linea mas im- 
portantes, los cuales pue- 
den verse en la figura 1 . 
Ahora, veamos varios ejem- 
plos con estos comandos. 

Situandonos dentro del 
directorio media probemos 
la siguiente linea: 

povray +iejemp1 .pov +oe- 
jempl .tga + d0-v+w320 
+h200-+lc\povray3\include. 

El fichero de ejemplo 
ejempl .pov sera procesa- 
do y se creara un fichero tga 
con el mismo nombre. POV 
autodetectara la tarjeta dis- 
ponible y visualizara la es- 
cena a una resolucion de 
320x200 pixels, sin antialias. 
Los ficheros include nece- 
sarios para la generacion se 
buscaran en la ruta indicada 
porel comando +L. 

Si ahora probamos nueva- 
mente la linea precedente 
ahadiendo +Q4, obtendre- 
mos un resultado mucho mas 
pobre a cambio de una ma- 
yor velocidad de generacion. 

Consejos sobre 
comandos de linea 

Como veremos mas adelan- 
te, antes de obtener el re- 
sultado'-final buscado en 
ha hay que realizar 



bastantes pruebas, hay que 
construir cada objeto, po- 
nerlo en su posicion ade- 
cuada, elegir las texturas, la 
iluminacion adecuada, etc. 
Una buena resolucion para 
una escena final puede ser 
800x600 pixels, pero resulta 
absurdo calcular las pruebas 
intermedias con estos valo- 
res. Normalmente 320x200 o 
incluso 160x100 pixels, sue- 
len ser cifras mas practicas 
para 'W'y'H' durante los ren- 
ders de prueba. Ademas de 
esto, puede usarse la opcion 
+SP con valores de 8 o 4. 

Tambien, conviene utilizar 
el buffer poniendo +B con 
valores de 64 o mas. De este 
modo, ahorraremos algo de 
tiempo y nuestros oidos su- 
friran menos con el ronroneo 
del disco duro. Rebajar la ca- 
lidad del render no es tan 
buena idea como en princi- 
pio pudiera parecer. La per- 
dida de calidad puede des- 
pistar bastante y, a la larga, 



hacernos perder el tiempo. 
Es preferible hacer pruebas 
parciales a calidad total y 
desactivar los elementos de 
la escena que no vayan a 
comprobarse en las prue- 
bas. Otra buena idea es de- 
sactivar el antialias (-A). El 
calculo del antialias siempre 
requiere tiempo adicional y 
solo tiene sentido activarlo 
en el render final. 

Por ultimo es conveniente 
conservar la posibilidad de 
poder interrumpir siempre la 
generacion de la imagen a 
golpe de tecla-(+X), ya que 
mas de una vez percibire- 
mos fallos garrafales mucho 
antes de que la escena se 
haya generado por comple- 
te). Si la interrupcion se efec- 
tua en medio de una imagen 
importante, para continuar 
con el la posteriormente bas- 
tara con ahadir +C a su linea 
de ordenes. Los comandos 
SC, EC, SR y ER, rara vez se 
emplean para nada. 



En cuanto al comando 'D', 
si se tiene una tarjeta minima- 
mente modema, lo mas con- 
veniente es usar +DGH o 
+DGT. No visualizar la ima- 
gen (-D) apenas ahorrara 
tiempo y perderemos la po- 
sibilidad de darnos cuenta 
pronto de si hay un error. 
POV, por defecto siempre 
genera un archivo tga. Si no 
especificamos un nombre 
para el, este sera output. tga. 
Si queremos evitar su crea- 
cion podemos hacerlo con 
-F pero..., ipara que hacer 
esto? Siempre puede ser util 
organizar y guardar cada 
prueba. Podemos examinar- 
las usando algun visor de fi- 
cheros graficos como al- 
chemy e incluso convertir los 
ficheros tga a jpg, si el espa- 
cio ocupado se dispara. Mas 
tarde volveremos nuevamen- 
te al aspecto "tiempo", ya 
que es un detalle crucial en 
el trabajo con un trazador 
de rayos. 
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El universe* tridim 



Escena 
iluminada 
con una 
fuente de 
color bianco. 



Podemos pensar en el 
universo virtual de POV 
como un espacio que 
se extiende 
infinitamente en todas 
direcciones. En este 
universo tridimensional 
todos los elementos: 
objetos, camaras y 
luces, han de tener 
una colocacion 
espacial que se 
declarara con tres 
valores de 

coordenadas para los 
ejes X,Y y Z. 

Si recordamos alsunas no- 
ciones basicas de geome- 
tria, sabremos que los ejes 
eran conceptos abstractos 
utilizados para situar puntos 
u objetos en el espacio. El 



punto donde se cruzaban 
los ejes era llamado "origen 
de coordenadas" y asumire- 
mos que es el centra del 
universo del Pov-espacio. 
Naturalmente, las coordena- 
das X,y y Z de este origen 
son <0,0,0>. Si imaginamos 
que este punto correspon- 
de al centra de nuestra pan- 
talla de ordenador, podre- 
mos visual izar el eje X como 
una linea invjgtateq 
rre horizontalmefife nuestro 
monitor, siendo el eje y una 
linea similar que cruza verti- 
cal mente el centra de la 
pantalla y el eje Z otra linea 
que corta perpendicular- 
mente el piano de la misma, 
entrando o saliendo de ella. 
De esta manera, y siempre 
asumiendo que el centra de 






la pantalla corresponde al 
origen de coordenadas, las 
posiciones del eje X, situa- 
das a la derecha del men- 
cionado origen, son positi- 
vas y las situadas a la 
izquierda negativas. Las po- 
siciones del eje y que que- 
dan por encima del origen 
son positivas, y las inferiores 
negativas. En cuanto al eje Z, 
asjjmiteojqsxiueja parte del 
mfgs©-^ue^g£qjfffi 
monitor es positiva y 
opuesta negativa. Todos los 
valores crecen positiva o ne- 
gativamente conforme los 
objetos se alejan del centra 
de coordenadas. 

Esta disposicion en la co- 
locacion y en el sentido de 
los ejes es totalmente arbi- 
traria y otros programas em- 
plean convenios diferentes. 
Por lo que respecta a las 
unidades utilizadas en Pov, 
podemos suponer que es- 
tan en metros, en micras, en 
anos-luz, o en cualquier otra 
medida mientras trabaje- 
mos de manera consistente 
y respetemos las relaciones 
de tamano entre objetos. 

Objetos virtuales 

El lenguaje escenico de 
Povray nos permite definir 
un universo tridimensional 
poblado de objetos virtua- 
les. Estos objetos pueden 
ser muy simples o extrema- 
damente complejos, de- 
pendiendo de lo que nues- 
tra imaginacion, habilidad 
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artistica, o paciencia, nos 
permitan. Podemos crear 
modelos complejos a partir 
de muchos objetos simples, 
situarlos en el espacio, ilu- 
minarlos, y enfocarlos con la 
camara desde cualquier po- 
sicion. Ademas, habremos 
de definir la apariencia de 
estos objetos. En el mundo 
real las superficies pueden 
ser rugosas o lisas, mostrar 
los caprichosos dibujos del 
marmol o las lineas ondula- 
das de la madera, exhibir 

, brillos metalicos, etc. 

^rgjsPOV, todas estas pro- 
pieladfljsedefinen en las 
texturas qu^ie dSKnana los 
objetos. Elegir /Ipl&r ce 
rrectamente las texturas en 
los objetos es algo tan vital 
como la propia forma de es- 
tos. La definicion de una tex- 
tura puede ser algo muy sen- 
cillo o bastante complejo 
pero no nos asustemos: POV 
incorpora una completa li- 
breria de texturas con apa- 
riencias de maderas, marmo- 
les, granitos, cielos, etc. 

Veamos el formato gene- 
ral que sigue la definicion 
de un objeto: tipo_obje- 
to{posicion_tamano_y_orie 
ntacion transformaciones 
textura{propiedades trans- 
formaciones) transforma- 
ciones} Las Haves definen el 
"ambito" de las sentencias 
que definen al objeto. O 
sea que las sentencias pro- 
pias de la definicion de la 
textura deben estar encerra- 



das entre las Haves corres- 
pondientes de la misma y 
lo mismo ocurre con las 
transformaciones espaciales 
del objeto. Si hay alguna 
Have de mas o de menos, o 
si la colocacion de las ins- 
trucciones no corresponde 
a la que debe ser en el 
apartado correspondiente,- 
obtendremos un error y la 
escena no se creara o cuan- 
to menos no se creara co- 
rrectamente. En cuanto a la 
palabra "transformaciones", 
se refiere a las transforma- 
ciones espaciales: trasla- 
cion, rotacion y escalacion 
y su uso es siempre opcio- 

ii. Tambien, es muy 

le^sJlJDc^cWise ■( 
efectue cada transforma- 
cion. Por ejemplo, en el for- 
mato general antes descrito 
la palabra transformacion fi- 
gure tres veces: en la prime- 
ra, la transformacion solo 
afectarfa al objeto en sf pe- 
ro no a la textura ya que la 
definicion de esta sigue 
despues. Por el contrario, la 
siguiente vez la transforma- 
cion afecta solo a la coloca- 
cion, escala y orientacion 
de la textura y no al objeto, 
que no sufre estos cam- 
bios. Esto es asf porque la 
palabra esta delimitada por 
las Haves de la definicion 
de la textura. 

Por ultimo: la tercera 
transformacion afectara por 
igual a la forma y a la textura 
del objeto. 



Fuentes de luz 

El universo espacial de POV 
esta, por defecto, a oscu- 
ras. Para poderveralgoten- 
dremos que crear, al me- 
nos, una fuente de luz. Las 
fuentes de luz son declara- 
das y tratadas como obje- 
tos, con la salvedad de que 
son puntos infinitamente 
pequenos: no pueden, 
pues, ser vistasya que care- 
cen de tamano y forma. Es- 
to es asi por cuestiones tec- 
nicas, ya que todos los 
rayos luminosos han de salir 
del mismo punto, lo que,a- 
su vez provoca los proble- 
mas mencionados al pnnci- 
icon las sombras 
verdad es que POV 
emplea diversos trucos pa- 
ra paliar estos problemas. 
En cuanto a los tipos de 
fuente, la mas utilizada y 
sencilla -y a la vez la que 
menos calculos requiere- es 
la fuente de tipo omnidi- 
reccional. Esta derrama su 
luz en todas direcciones, tal 





Una vista de 
nuestra casa 
desde una 
camara 
diferente de 
POV. 
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como lo hace, por ejemplo, 
el sol. Vearnos como crear 
una fuente de este tipo: 

light_source { <30, 20, - 
50> color White} 

Como vemos los datos 
de la fuente de luz quedan 
encerrados entre Haves, de 
manera similar a como su- 
cedia en los objetos virtua- 
les. Las Haves que delimitan 
la definicion de esta fuente 
engloban dos datos: un 
vector utilizado para indicar 
la posicion espacial de la 
fuente en el universo virtual, 
y el color de la misma. Los 
vectores son profusamente 
utilizados en POVy mas tar- 
de los trataremos con ma- 
yor detalle. En este momento, 
nos bastara con saber que el 
vector del ejemplo senala la 
posicion X, y y Z de la fuente. 
Despues del vector, sigue la pa- 
labra reservada "color", la cual 
se emplea para especificar 
aquello que su nombre indica. 

Una de ellas es precisa- 
mente la empleada en el 
ejemplo anterior: la palabra 
White (bianco) es en reali- 
dad un identificador o ma- 
cro definida con #declare 
en el fichero de inclusion 
colors. inc. Si incluimos en 



nuestro fichero escenico la 
sentencia precisa (#inclu- 
de) para cargar este fichero 
inc, podremos referenciar 
cualquier identificador in- 
cluido en el mismo. El fun- 
cionamiento de esta espe- 
cie de macro es muy 
sencillo: al hallar el nombre 
del identificador, Pov lo 
sustituye por el texto que, 
en la declaracion, sigue al 
identificador. Esta potente 
idea, que examinaremos en 
profundidad en la senten- 
cia #declare, es la base de 
gran parte de la potencia 
del lenguaje de POV. El lec- 
tor puede examinar el fi- 
chero colors. inc (en el di- 
rectorio include) para 
comprobar la lista de colo- 
res "declarados" por POV. 

(Es muy importante recor- 
dar que POV distingue entre 
mayusculas y minusculas. 
Cuando usemos una senten- 
cia o un identificador tendre- 
mos que escribirlo tal como 
se indique. En el ejemplo an- 
terior white o WHITE no se- 
rian reconocidas por POV y 
obtendriamos un error). 

En el fichero colors. inc 
viene definido un buen nu- 
mero de colores pero, te- 



niendo en cuenta que mu- 
chas tarjetas pueden mostrar 
hasta 16 millones de colores, 
es obvio que necesitamos un 
metodo alternativo para es- 
pecificar el color de la fuente 
de luz o de los objetos. 

El color 

El sistema RGB utiliza una 
mezcla de tres colores pri- 
marios para representar 
cualquier color. Es el siste- 
ma utilizado por los televi- 
sores a color y el empleado 
tambien por POV. Por tanto, 
deberemos definir cual- 
quier color utilizando inten- 
sidades de red (rojo), green 
(verde) y blue (azul). POV 
emplea varias sintaxis para 
especificar colores. Una de 
ellas, algo antigua ya, es: co- 
lor red 1 green blue 0. 

Los valores en formato 
flotante que siguen a cada 
color primario indican la 
fuerza del mismo y pueden 
oscilar desde (nada) a 1 
(maxima intensidad). 

El ejemplo anterior es, 
evidentemente, la defini- 
cion del rojo puro y, como 
los otros dos componentes 
estan a cero, podemos es- 
cribir tambien: color red 1 . 

Pero esta sintaxis es algo 
engorrosa y por ello la si- 
guiente linea tambien es va- 
lida: color rgb <1, 0, 0>. 

De hecho, tambien pode- 
mos precindir tranquila- 
mente de la palabra color y 
limitarnos a: rgb <1,0,0>. 

Ademas, por una propie- 
dad de POV llamada "pro- 
mocion de operadores", es 
valida una linea como: rgb 1 . 
...que es la definicion del 



color bianco. Ahora pase- 
mosaotrosdetalles. 

Realmente, la especifica- 
cion de un color, aunque 
puede limitarse a tres valo- 
res, puede emplear hasta 
cinco componentes. El 
cuarto es llamado filter (fil- 
tro) y se usa para indicar la 
cantidad de transparencia 
deun material. 

Un valor de cero en este 
componente senala una 
opacidad total y un valor 
de una transparencia total. 
Vearnos la definicion de 
color usada en el fichero 
glass. inc para crear una tex- 
tura empleada para las bo- 
tellas de vino: color rgbf 
<0.4, 0.72, 0.4, 0.6>. 

El cuarto valor equivale a 
una transparencia del 60%. 
Como podemos suponer, 
aun sin efectuar ningun ren- 
der, el color del material se- 
ra mas bien verde, ya que 
tiene un fuerte valor en este 
componente. En cuanto al 
quinto componente, indica 
la cantidad de luz no filtra- 
da que se transmite a traves 
de una superficie. Ejemplos 
de este tipo de transparen- 
cia (que no existia antes de 
la version 3.0) pueden ob- 
servarse en cortinas o telas 
finas. Este componente es 
llamado transmit y podemos 
agregar una 't' a la palabra 
rgb para aludirlo. Asi usando 
rgbt, el cuarto valor corres- 
ponded a este componen- 
te y en rgbft al quinto. 

Por ultimo, hemos de tener 
en cuenta que, al igual que 
sucede con el mundo real, el 
color de un objeto depende 
tambien de la fuente de luz, 
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sobre todo si la superficie 
del objeto permite un alto 
indice de reflexion. 

La camara: como 
situarla y orientarla 

Al igual que sucede con las 
fuentes de luz, las camaras 
son objetos invisibles. Cada 
escena debe incorporar 
una definicion de la camara 
que va a sacar la "fotogra- 
fia". En dicha definicion le 
indicaremos al prosrama 
donde situar nuestra camara, 
hacia donde va a mirar, si va 
a tener zoom o no, etc. Asi, 
como vemos, en la coloca- 
cion de las camaras tiene lu- 
sar un proceso muy similar 
al sesuido por un fotografo 
oun director de cine. 

(Sobre todo porque exis- 
te la posibilidad de crear 
peliculas con las imagenes 
generadas con POV). 

Aquf tenemos una posi- 
ble definicion para la cama- 
ra de una escena: camera { 
location <0, 145, -120. 0> 
direction <0.0, 0.0, 1 .5> up 
<0.0, 1.0, 0.0> right 
<1 .33,0.0, 0.0> look_at <3, 
10, 0.0 >}. 

La colocacion de la ca- 
mara en el espacio se logra 
con la instruccion Location. 
Esta sentencia utiliza tres 
numeros que indican la co- 
locacion de nuestra camara, 
con respecto al origen de 
coordenadas. En el ejem- 
plo anterior, nuestra camara 
estara situada a 120 unida- 
des fuera del monitor (si 
damos por valido el ejem- 
plo que se comento al ex- 
plicarel sistema de coorde- 
nadas, donde se dijo que el 



valor de Z estaba situado 
en el piano de la pantalla. 
Segun este mismo ejemplo, 
si el valor 1 20 fuera positivo, 
la posicion caeria dentro 
del monitor y la escena se 
enfocaria desde el lado 
opuesto). Ademas, la cama- 
ra se posicionara a 145 uni- 
dades por encima del ori- 
gen (por el valor del eje Y). 
Look_at es, aparte de lo- 
cation, la instruccion mas 
importante dentro del gru- 
po de las que componen la 
declaracion de la camara. 
Especifica la posicion hacia 
la que esta va a mirar, for- 
zandola a girarse para enfo- 
car la posicion espacial in- 
dicada en el vector que 
sigue a look_at. En el ejem- 
plo anterior, la camara enfo- 
caria un punto colocado a 
la derecha y un poco por 
encima del origen de coor- 
denadas (ya que Z=0). La 
sentencia direction indica la 



direccion inicial de enfo- 
que de la camara, direccion 
que, luego, puede ser cam- 
biada por las sentencias lo- 
ok_at,, rotate u otras. La li- 
nea de enfoque de la 
camara sigue el camino in- 
dicado por el vector de di- 
rection (normalmente 
<0,0,1>). La longitud de es- 
te vector, 1 .5 en el ejemplo, 
tambien afecta la distancia 
de la ventana de vision a la 
camara. Una valor grande 
da como resultado un cam- 
po de vision corto, ya que 
el piano de vision quedara 
muy proximo a la camara. 

La instrucciones up y right 
definen respectivamente la 
direccion vertical y horizon- 
tal del piano de vision. Tam- 
bien afectan al aspect ratio 
de la imagen a "fotografiar". 
En el ejemplo, up tiene el va- 
lor 1 en el eje y vertical y right 
el valor 1 .33 en el eje X. Con 
ello, se indica que la camara 



no tiene ninguna inclinacion 
con respecto al piano X,Z, tal 
como sucederia si estuviese 
apoyada en un tripode que- 
dando paralela al suelo. En 
cuanto al valor 1 .33, normal- 
mente las resoluciones para 
las imagenes a generar suelen 
ser de 640x480, 800x600, 
1024x768, etc. Estos valores 
tienen una relacion de 1.33 
(640/480, 800/600, etc). Por 
ello, colocando esta relacion 
en right se efectua una com- 
pensacion, de modo que los 
objetos no quedan distorsio- 
nados. En las figuras pode- 
mos ver un ejemplo, cuya 
longitud es identica en los 
ejes X e Y 

Teoricamente, usando tan 
solo las sentencias location, 
direction, up y right, resulta 
posible colocar y orientar la 
camara de cualquier forma 
pero, en la practica, esto es 
muy dificil, y por ello, conta- 
mos con la ayuda de look_at. 




T^eHdeMtt&ttia 1 7 
iKj\ (wJ\. (w^\ (0JK (wJSk (w^A (wJk (w^j\ (wJ\ (mJk (w^A (wJk (wJS, (w^A (wJk (wJk (wJ\ (wJk d 



r \ 





V 



Primitivas 
complejas de 
POV: objetos 
fractales. 



Componentes del 



Los componentes del 
lensuaje escenico de 
POV son 
identificadores, 
sentencias, vectores, 
cadenas, simbolos 
especiales y 
comentarios. Todos 
estos elementos 
pueden usarse de una 
forma bastante libre 
para construir un 
fichero escenico. 

No hay tabulaciones deter- 
minadas ni es preciso seguir 
un orden concreto en la co- 
locacion de los elementos, 
si bien es adecuado atener- 
se a algun tipo de formato 
porcriterios de claridad, so- 
bre todo si se va a desarro- 



llar un proyecto mediana- 
mente complejo. En 
town.inc se advertira un esti- 
lo determinado que el lec- 
tor puede sustituir tranquila- 
mente por otro con el que 
se encuentre mas comodo. 
Veamos ahora algo sobre los 
componentes del lenguaje. 

Instrucciones e 
identificadores 

El lenguaje escenico del 
POV consta de una larga lis- 
ts de instrucciones y pala- 
bras reservadas utilizadas 
como parametros en dichas 
sentencias. El lector puede 
observaresta lista en la figu- 
ra sin sentir escalofrios,- en 
principio basta con saber 
emplear bien unas cuantas 




sentencias y reglas para po- 
der realizar escenas bastan- 
te vistosas. La primera regla 
a recordar es sencilla: POV 
nos permite crear palabras 
para declarar objetos, colo- 
res, texturas, etc., y no po- 
dremos utilizar para ello 
ninguno de los nombres de 
la figura, dado que ya que 
estan reservados para un 
uso determinado. Por ello, 
estos nombres, ya sean de 
instrucciones o de parame- 
tros, reciben tambien el 
nombre de palabras reser- 
vadas. Por otra parte, las 
posibles palabras defini- 
bles por el usuario son lla- 
madas identificadores. Los 
identificadores pueden te- 
ner hasta cuarenta caracte- 
res de largo y se escriben 
con cualquier caracter alfa- 
betico o numerico, ademas 
de con el caracter '_'• (Aun- 
que el primer caracter del 
identificador debera ser al- 
fabetico y no numerico). Fi- 
nalmente, debemos recor- 
dar que no se permiten 
espacios dentro del nom- 
bre del identificador. Los 
identificadores se crean 
con #declare. Por ejempb: 
#declare Chrome_Metal = 
texture { Chrome_Texture }. 
Esta linea crea la textura 
Chrome_Metal. 

Comentarios 

Todos los lenguajes de pro- 
gramacion tienen la posibi- 
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lidad de incluircomentarios 
a fin de facilitar la compren- 
sion del programa. Esta po- 
sibilidad es especialmente 
util cuando un programador 
debe estudiar listados aje- 
nos. Pero incluso aunque el 
listado sea propio puede 
ocurrir que, con el paso del 
tiempo, ciertas lineas espe- 
cialmente complejas se ha- 
gan dificiles de entender. 
Esta situacion, tambien 
puede darse con el lengua- 
je escenico y, por ello, el 
pov-team ha incluido la po- 
sibilidad de introducir co- 
mentarios. Un comentario 
puede constar de una o 
mas lineas de texto delimi- 
tadas por separadores y, su 
contenido, no tiene ningun 
efecto para la creacion de 
la escena. Tan solo servira 
para hacer mas comprensi- 
ble al lector el significado 
del listado. Los comentarios 
del lenguaje escenico del 
POV utilizan las mismas re- 
glas que los del C y C++. O 
sea una doble barra para los 
comentarios de una sola li- 
nea y los caracteres /* y */ 
para los de una o mas lineas. 
Veamos unos ejemplos: // 
Esta linea es un comentario 
y el POV la ignora /* Esta If- 
nea es ignorada por el "inter- 
prete" que efectua el proce- 
so de parsing del POV. De 
hecho, todo es ignorado 
hasta el final de esta linea */. 
Tambien, es posible insertar 




un comentario despues de 
un trozo de linea "util" del 
siguiente modo: object 
{cualquier_cosa) //El POV 
solo ignora esta frase. 

Los comentarios tambien 
son muy utiles cuando se de- 
sea eliminar temporalmente 
un trozo de escena consis- 
tente en una o mas lineas. Es 
mucho mas facil recuadrar el 
trozo con los simbolos de 
marca de comentario que 
simplemente borrarlo y vol- 
verlo a escribir despues. 

Valores en formato 
flotante 

El manual de POV define un 
vector como un conjunto 
de valores en flotante. 

(El formato flotante es 
empleado para almacenar 



numeros con un compo- 
nente real y otro entero). Un 
vector puede tener de 2 a 5 
componentes separados 
por comas y delimitados 
por los caracteres '<' y '>'. 
Los vectores pueden estar 
compuestos por expresio- 
nes numericas, identificado- 
res o funciones que retornan 
valores. Ejemplos validos de 
usode vectores son: 
translate<Col2 ,Row1 ,Dist> 
scale <1 ,2.1 ,-25.4578> 
location<posX,posY+1 5,- 
20> 

translate <anos_luzX/densi- 
dad_estelar ,ahos_ luzY+rand 
(a)+12,100>. 

Naturalmente, el numero 
de componentes de un 
vector dependera de la pa- 
labra que preceda a dicho 
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ciones (declaraciones) de 
objetos o cosas que pue- 
dan ser referenciadas una o 
muchas veces por los fiche- 
ros principales de escena. 
La mecanica de uso de los 
archivos de inclusion es la 
siguiente: en un lusar dado 
del archivo de escena, ge- 
neralmente al principio del 
mismo, se suelen colocar 
una o mas instrucciones co- 
mo la que sigue: #include 
.inc". 
JncgjL^QLdenamos < 

POV genCTaT^najTOagen, e 
primer paso qu^eaHJEies 



vector. En rgbft seran 5, en 
una sentencia location se 
precisaran 3, etc. 

"Parsing" y ficheros 
include 

En POV, los archivos inclu- 
de son ficheros de texto en 
formato ASCII escritos con 
declaraciones o instruccio- 
nes del lenguaje escenico 
del Ray-tracer. No se em- 

completas por si 
aunque si incorporan ele- 
mentos para el las. Su filoso- 
fia consiste en incluir defini- 

Figura 1: "Palabras reservadas de Povray" 
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comenzar a leer el fichero 
escenico suministrado co- 
mo entrada. Mientras el fi- 
chero se lee, POV va inter- 
pretando lo leido y 
creando un modelo interno 
de la escena. A este proce- 
so se le llama "parsing", y 
"parser" a la parte de POV 
encargada de dicho proce- 
so. Pues bien, cuando du- 
rante el parsing del fichero 
dado como entrada, el par- 
ser halla una linea como la 
anterior, POV carga el fiche- 
ro indicado en la sentencia 
#include y procede a inter- 

retarlo. Al acabar con el, 

£rser continua leyendo 

e inrei|freSfTelpJas lineas 

del fichero . 

La sentencia #inclu3e si 
emplea para dar claridad a 
nuestros proyectos, ya que 
elimina la necesidad de te- 
nerlo todo en un unico fi- 
chero. Asi, podriamos crear 
5 tanques diferentes en 
otros tantos ficheros inclu- 
de y dejar en el fichero 
principal (el dado como 
entrada a POV) las senten- 
cias de camara, luces y co- 
locacion de los tanques. 

Para funcionar, #include 
precisa que los ficheros .inc 
se encuentren en el directo- 
rio en curso, o bien en el di- 
reccionado por la orden de 
la linea de comandos +L. 
Povray adjunta en el direc- 
torio include varios archivos 
de inclusion con declara- 
ciones de colores 
(colors. inc), texturas (wo- 
ods, stones...), etc., que 
nos seran muy utiles. Sin 
embargo, como los ele- 
mentos declarados ocupan 



espacio en memoria, no 
conviene "incluir" ficheros 
que no vayamos a emplear. 

#Declare 

Los ficheros de inclusion 
utilizan mucho la instruc- 
cion #declare. Esto es'asi 
porque esta sentencia ayu- 
da considerablemente a es- 
tructurar las archivos esceni- 
cos, y hacerlos mucho mas 
cortos y sencillos. Con #de- 
clare se puede hacer que 
un identificador equivalga a 
una larga y compleja serie 
de sentencias que podran 
ser referenciadas mas tarde 
cuantas veces lo deseemos, 
simplemente incluyend' 

jiprTfflJeQIirfepae 

Tjsarse para declarar un 
color, una textura compleja, 
un objeto o parte del mis- 
mo, un vector, un valor en 
flotante, una operacion CSG, 
una camara, etc. Con #de- 
clare bastara con cambiar la 
declaracion que sigue a esta 
sentencia para que la altera- 
cion se haga efectiva en to- 
dos los sitios donde se haya 
colocado el identificador, 
con el consiguiente ahorro 
de tiempo y trabajo. 

Un detalle adicional muy 
importante es el hecho de 
que la declaracion de un 
nuevo identificador puede 
apoyarse en otros identifi- 
cadores ya creados. 

Veamos un ejemplo vali- 
do extraido de colors. inc 

#declare White = rgb 1 

#declare Gray05 = Whi- 
te*0.05 

Aqui el color bianco defi- 
nido es empleado en la de- 
finicion del gris. Mas tarde, 
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al estudiar town.inc, vere- 
mos como se emplea #de- 
clare para definir objetos 
simples usados en la cons- 
truccion de otros mas com- 
plejos (por ejemplo, venta- 
nas para las paredes, grupos 
de paredes para los pisos, 
pisos para las casas y grupos 
de estas para un pueblo). 

Otra caracteristica muy 
importante de #declare es 
que los identificadores cre- 
ados pueden ser redeclara- 
dos utilizando el valor ante- 
rior del identificador. Asi, 
por ejemplo, es posible es- 

ribir... 

#declare X=5 

#declare x1=X+7 

#declaretotal=x1*(X+10) 

Donde el valor de "total" 
es de 180. La utilidad de to- 
do esto se hara evidente 
luego, cuando estudiemos 
las sentencias #if, #while y 
otras. Una declaracion 
siempre empieza, como 
podemos ver, con la pala- 
bra #declare seguida del 
identificador. Luego, se po- 
ne un signo '=' al que segui- 
ra la definicion de la decla- 
racion. (Recordemos otra 
vez que POV distingue en- 
tre mayusculas y minuscu- 
las. No sera igual "total" que 
"Total"). Los identificadores 
creados han usarse de ma- 
nera logica. Es decir, si el 
identificador es un objeto, 
tendra que ser referenciado 
dentro de una palabra ob- 
ject. Si es una textura, ten- 
dra que colocarse dentro 
de una sentencia texture, 
etc. Veamos un ejemplo: 

#declareP_Gold2=rgb 
CVectS 



#dec!are F_MetalA =finish { 

brilliance 2 

diffuse D_GoldA 

ambient A_GoldA 

reflection R_GoldA 

metallic M 

specular 0.20 

roughness 1/20 

} 

#declare T_Gold_2A = 
texture { pigment { P_Gold2 
} finish { F_MetalA } } 

Como puede verse, la de- 
finicion de la textura 
T_Gold_2A emplea el color 
P_Gold2 y el acabado 
F_MetalA (finish) definidos 
anteriormente. (Para la defi- 
nicion de estas caracteristi- 
cas, la textura emplea las 
palabras pigment y finish, 
de las que hablaremos mas 
adelante). 

La declaracion de un obje- 
to tampoco tiene misterios: 

#declare bola=sphere{ 
<0,0,0>, 1 } 

El objeto declarado, ya 
sea sencillo como bola o 
muy complejo, puede ser 
invocado despues en tan- 
tos sitios como deseemos 
empleando la sentencia 
object del siguiente modo: 

object { bola 

texture{T_Gold_2A) scale 
<2,1,3>) 

object { bola 

texture{T_Silver_4A) transla- 
te <10,20,30> } 

Notese como el identifi- 
cador del objeto bola es 
usado para crear dos obje- 
tos situados en posiciones 
y escalas diferentes, y que 
pueden llevar texturas dis- 
tintas. (siendo una de estas, 
la declarada en el ejemplo 
anterior). 



Tipos de objetos 
dePOV 

Llamaremos figuras primiti- 
vas -o primitivas a secas- a 
los objetos simples que se 
definen con las sentencias 
reservadas para ello como 
sphere, box, plane y otras. 
Aquellos objetos mas com- 
plejos, resultantes de las 
operaciones hechas entre 
objetos, no seran conside- 
rados como primitivas. A su 
vez, las primitivas pueden 
ser finitas o infinitas. Una es- 
fera es un objeto finito, ya 
que siempre tiene limites 
definidos sin importar cuan 
grande pueda llegara ser. La 
primitiva plane, en cambio, 
tiene las mismas propieda- 
des que el piano matemati- 
co. O sea, carece de grosor 
y se extiende infinitamente 
por el espacio virtual. 

La filosofia del modelado 
en POV se basa en operar 
con estas primitivas para 
construir objetos. Los obje- 
tos resultantes pueden su- 
marse o combinarse entre si 
para producir objetos aun 
mas complejos que pueden 
emplearse para crear mode- 
los de mayor complejidad. 



Primitivas 

La esfera es una de las pri- 
mitivas de mas rapida inter- 
pretacion de POV. 

Este objeto es generado 
con la sentencia sphere, cu- 
ya sintaxis es: spheref <cen- 
tro>, radio }. 

<Centro> es un vector 
que define los valores de 
X,y y Z para la localizacion 
espacial del centra de la 
esfera. 

Despues, separado por 
una coma, sigue el radio de 
la esfera. Tambien, pode- 
mos generar esferas con 
otras sentencias como cua- 
dric pero sphere es mas ra- 
pida. Un ejemplo sencillo 
es: sphere{<-12,4,0>,4 tex- 
ture{T_Stone23} }. 

Esta linea creara una esfe- 
ra de 8 unidades de diame- 
tro con una apariencia de 
piedra (textura T_Stone23) 
en la posicion indicada por 
el vector. 

Otra primitiva sencilla y 
de rapido dibujo es box 
(caja). Un ejemplo sencillo 
de box seria un cubo o, da- 
do que la longitud de la 
forma no tiene porque ser 
la misma en los tres ejes, 
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una caja de zapatos. La fi- 
gure se define especifican- 
do las posiciones espacia- 
les de dos vertices 
opuestos de la misma. Am- 
bos vertices son definidos 
por dos vectores separados 

or comas, con lo que la 
is de la caja queda 
como sigue: bdx{<esqui- 
na1>,<esquina2> }. 

Tambien se supone que 
cada uno de los lados-es 
siempre paralelo a uno de 
los ejes de coordenadas. 
Solo posteriormente, con el 
empled de sentencias de 
rotacion, esta situacion ini- 
cial puede alterarse. Otro 
detalle importante a tener 
en cuenta es que el primer 
vector de la definicion de- 



be referirse siempre al pun- 
to con los valores X,Y y Z 
mas pequenos. 

Un ejemplo: box{<- 
25,0,0> , <25,50,5> textu- 
re{textmur} }. 

La siguiente primitiva a es- 
tudiar es el cilindro. La sen- 
tencia empleada para crear 
estos objetos es cylinder, y 
su sintaxis es... 

cylinder{<base>, <ci- 
ma>, radio } 

Los dos vectores indican 
las coordenadas X,Y y Z del 
punto central de cada ex- 
tremo del cilindro (de la 
basey lacima). 

El valor de "radio" especi- 
fica el radio del objeto. El 
cilindro creado aparecera 
como un objeto "solido" a 



menos que escribamos la 
palabra "open" despues 
del radio. En este caso, se 
eliminaran los pianos que 
forman las dos bases del ci- 
lindro, con lo que este que- 
dara hueco y sus paredes 
careceran de grosor. Debi- 
do a este ultimo detalle no 
se empleo open en los ci- 
lindros que definian las to- 
rres de castlib, ya que se 
pretendia que las torres, 
aunque huecas, tuviesen 
muros de un grosor dado. 
Por esta razon, la forma ba- 
sica de las torres se creo 
usando operaciones CSG 
entrecilindros. 

(Ver PCmania numero 47). 
Aqui tenemos un ejemplo 
de cylinder: 



cylinder {<6,4,0>, 

<6,14,0>, 4 pigment {Red} } 

(Pigment se emplea para 
crear una textura consistente 
en un color para el cilindro). 

Continuemos con el si- 
guiente objeto: el cono. Su 
filosofia y sintaxis son muy 
similares a las del cilindro. 
La unica diferencia estriba 
en que ahora cada uno de 
los extremos del objeto I le- 
va un radio propio. Tambien 
podemos emplear la pala- 
bra open despues del se- 
gundo radio con el mismo 
resultado que antes. La sin- 
taxis para este objeto es... 

cone {<base>, radiojoa- 
se, <techo>, radio_techo } 
...y el ejemplo correspon- 
diente... 
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cone{ 

<-1 2,1, 0>,5// Centra yra\ 
dio de uno de los extremos 
<-12,8,0>,3// Center 
y radio del otro extremo 
pigment {Cyan} 
} 
Si se desea que el cono 
acabe en un unico punto, 
debe darsele radio cero a 
uno de los extremos. 

Objetos infinitos, 
superficies 
matematicas y 
plane 

Todos los objetos estudia- 
dos hasta ahora son finitos 
pero POV permite crear 
objetos con superficies in- 
finitas. Tal es el caso del 
piano, el cual es sumamen- 
te util en las operaciones 
CSG. Otras primitivas que 
pueden caer en esta cate- 
goria son cubic, poly y 
quartic, las cuales descri- 
ben objetos basados en 
ecuaciones polinomicas. 
El calculo de estas superfi- 
cies es lento y a veces no 
muy fiable. Ademas, pre- 
decir la forma final exacta 
de este tipo de objetos es 
dificil, por lo que estas pri- 
mitivas solo suelen ser usa- 
das por programas de mo- 
delado. Por estas razones 
nos limitaremos a estudiar 
la primitiva "plane". 

La palabra "plane" sirve 
para crear un piano, infini- 
te) en dos de los ejes y ca- 
rente de longitud en el eje 
restante. Dicho piano pue- 
de ser utilizado como sue- 
lo o pared y puede recibir 
texturas en su superficie, o 
bien ser utilizado, como 



rial 



ano ' 



flairs 



\vere\mos\ mas adelante, ei\ 
5per*aciories\,de CSGv El 

piano tiene dos pbsib'les 

\ \ \ \ \ \ 
forrnatfos, amops taual 

\mertte validos, el primero y • 

\ X \ \ \ 

oas antiguo es: plane { 

<xy/,z>y distanc^ }. 

DbndeXel vCcto\<x, 
se retierexa la\nor 
piano de superficie. 

(La norhnal a\jn cH 
un vector -touede vis\|ali- 
zarse como\ina 
que abandona et> 
manera perpendicular^ 
este, o sea como un pgste 
en relacion al suelo. Sc 
biendo esto es facil imagi- 
nar que un vector paralelo 
al eje y puede servirnos 
para crear un suelo mien- 
tras que otro paralelo al eje 
Z podria utilizarse para di- 
bujar un muro paralelo al 
piano que forma la panta- 
lla). El parametro siguiente 
es un valor en flotante que 
indica la distancia del pla- 



(o al origen d? cobrde'rca- \ 
das. De estsforrna ehejerrit 
plo\siguiente\.. \ 
pla'ne { <0,V;Q>,5 
inciica que la nOTrnal\ 
sera\perp.end)cularaj pW 
fomnadcxporips e)ss X 
conMp que obte,ndrex 
plajio pa^ralek) a 
dicbos kjes y\ituablo a 
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origen a&coonsena 
X EI signo dHyalobcorre 
liente^al ejesjrve tant 
inaicar HsentMp e 
quests normal se^sleja 
en como para sabei^en 
rado cteL eje oeben 
cohtarse lasunidasles pa 
situareSplano 

Dado queNtambrefupo 
demos indicar valores ne 
gativos en el valor que 
gue al vector, la decision 
acerca del lado del eje en 
que finalmente debe si- 
tuarse el piano, puede pa- 
recer un tanto liosa. 
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Texturas, col ores y 



Ejemplo de la 
libreria de texturas 
de POV:oro. 



Ya sabemos bastante 
acerca de como crear 
objetos. De hecho, 
aunque no lo parezca, 
todos los modelos de 
Castlib se nan creado 
partiendo de opera- 
ciones entre las primiti- 
vas ya estudiadas (tam- 
bien se ha empleado 
prism para puertas y 
ventanas). 

Aun no se ha tocado el te- 
rra de la apariencia de los 
objetos a pesar de que este 
asunto es de una importan- 
cia capital, ya que sin una 
textura que describa el ma- 
terial de una superficie, no 
sera visible. 

Materiales 

Comencemos con ello 
pues: para crear la aparien- 
cia de un material, el poten- 
te lensuaje de POV nos 
ofrece varias docenas de 
sentencias que empleare- 




mos para definir los ele- 
mentos constituyentes de 
las texturas: pigmentos, nor- 
males, acabados y halos. 
Un pigmento es el color o 
patron de colores del mate- 
rial o bien el bitmap que lo 
recubre. El pigmento se de- 
fine con sentencias englo- 
badas dentro de las Haves 
de la sentencia pigment. 
Hay que decir que estos 
colores son los "reales" del 
objeto pero, bajo ciertas 
condiciones, no siempre 
seran los que se aprecien al 
obtener la imagen. Por 
ejemplo, si un objeto tiene 
un pigmento bianco y colo- 
camos una luz verde cerca 
de el, el objeto presentara 
un aspecto verdoso. En 
cuanto a "normal", la sen- 
tencias escritas dentro de 
esta instruccion se emplean 
para crear apariencias tales 
como abolladuras, anillos, 
ondulaciones, etc., en el 
material. El nombre de esta 
sentencia hace referenda al 
metodo empleado para 
conseguir estos aspectos, 
logrados gracias a la distor- 
sion de las normales en la 
superficie del objeto don- 
de se aplica la textura. Es 
importante recordar que la 
superficie de los objetos no 
se vuelve realmente irregu- 
lar. Se trata tan solo de un 
truco que quedara en evi- 
dencia si observamos los 
bordes de las formas que 



empleen texturas de este ti- 
po. El siguiente apartado es 
el acabado, el cual se ob- 
tiene gracias a las senten- 
cias empleadas para la ins- 
truccion finish. (Aqui la 
palabra acabado alude a las 
propiedades reflectivas y 
refractivas del material). Por 
ultimo, el apartado halo, in- 
corporado a partir de la 
version 3.0 de POV, se em- 
plea para simular efectos 
de nubes, niebla, fuego, 
etc., dentro de los objetos. 
Una pov-textura puede 
ser de tipo sencillo o de ti- 
po especial. A pesar de su 
nombre, las texturas de tipo 
sencillo pueden ser muy di- 
ficiles de crear, dependien- 
do de lo que pretendamos 
hacer. El formato complete 
para una textura sencilla es: 
texture { 
identificador_de_Textura 

pigment {..} 

normal {..} 

finish {..} 

halo{..} 

Transformaciones 

} 
Las lineas anteriores po- 
drian incluirse dentro de las 
Haves de un objeto de este 
modo: 

box{<-4,2,-4>,<4,10,4> 

texturefdefini- 

cion_de_textura) 

} 

Sin embargo, es mucho 

mas comodo declarar un 

identificador para la textura. 
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De este modo, la textura 
definida podra ser emplea- 
da por tantos objetos como 
queramos sin necesidad de 
escribir todas las veces la 
misma definicion. Porejem- 
plo, podriamos escribir: 

#declare madera=textu- 
re{definicion_de_textura} 

box{<-4,2,-4>,<4,10,4> 
texture{madera} 
1 
sphere{<12,15,23>, 4 
texture{madera} } 

Por otro lado, cada una 
de las Ifneas que anterior- 
mente vimos en el formato 
completo de la declaracion 
de la textura pertenece a un 
apartado opcional en dicha 
declaracion, aunque hay 
una excepcion para esto: si 
"identificador_de_Textura" 
no se incluye, deberemos 
forzosamente dar un pig- 
mento a la textura. De he- 
cho, existe una forma abre- 
viada de definir una textura 
donde solo se precisa defi- 
nir el pismento. Asi, la si- 
guiente linea es correcta: 
sphere{<2,75,13>, 6 pig- 
mentfWhite} } 

Realmente, lo que sucede 
es que se aplican los valores 
de la textura por defecto pa- 
ra normal y finish. En caso de 
que pretendamos crear 
nuestra propia textura por 
defecto, podemos hacerlo 
usando la sentencia #default. 

La siguiente linea, por 
ejemplo, cambiaria el valor 



por defecto de finish: #de- 
fault{finish{ambient .7} }. 

Antes de continuar, con- 
viene tomar nota de una sen- 
tencia usada en pigment que 
nos sera muy util en las prue- 
bas. Se trata de checker. Esta 
instruccion crea una trama 
de pigmentacion tridimen- 
sional compuesta porcubos 
de colores alternos. La longi- 
tud de las aristas de cada cu- 
bo de color es de una uni- 
dad y la orientacion de los 
cubos es paralela a los ejes 
del universo virtual. 

La importancia de che- 
cker radica en que equivale 
a una especie de grid tridi- 
mensional: un fondo con el 
que nos sera facil compro- 
bar si son correctas la colo- 
cacion, orientacion y escala 
de los objetos en construc- 
cion. El autor de estas lineas 
emplea mucho esta senten- 
cia en la aplicacion de las 
primitivas con las que hace 
el suelo sobre el que iran 
los objetos en fase de de- 
sarrollo. Mas tarde veremos 
muchos ejemplos de esto. 

Por ahora, veamos un 
ejemplo de checker: 

box{<-4,-4,-4>,<4,4,4> 
pigmentfchecker pig- 
mented}, pigmentf/ellow}} 
} 

Esto puede abreviarse: 
box{<-4,-4,-4>,<4,4,4> 
pigmentfchecker Red, 
Yellow}} 

} 



Al igual que otras senten- 
cias usadas en texturas, 
checker no limita su uso a 
un solo tipo de componen- 
te de texturas. Tambien 
puede ser empleada para 
alterar las normales del ma- 
terial. Por ultimo, los pov- 
expertos deben tomar nota 
de que checker ha reem- 
plazado a tile para crear pa- 
trones ajedrezados de tex- 
turas. Por ejemplo... 

plane{y,2 texture { che- 
cker texture{T_Wood3}, tex- 
ture{T_Wood2}} } 

...crea un tablero de aje- 
drez de infinitas casillas alter- 
nando el uso de dos texturas 
de madera de la libreria. 

Otro detalle muy impor- 
tante para la declaracion de 
texturas es el hecho de que 
podemos aprovechar textu- 
ras ya creadas para definir 
las nuevas (lo cual tambien 
es valido para el caso de 
los pigmentos). En el for- 
mato completo de la decla- 




Ejemplo de la 
libreria de 
texturas de POV: 
piedra y madera. 




Ejemplo de la 
libreria de texturas 
de POV: cielo. 
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radon de textura sencilia 
que estudiamos anterior- 
mente figuraba la palabra 
identificador_de_Textura, la 
cual es, sencillamente, el 
nombre de una textura ya 
declarada antes. Al incluir el 
ntificadorde una textura 
ya.creada aLprincipk) de 
nuestra declaracibn, auto- 
maticamente''nuestwiextu- 
asara a tener los mismos 
cgrnponentes, ,-- pigment, 
normaV-fifiish v jialo de, 
aquella. Cuatquier cambio 
especifj.qu€mos 

iche>?"compQn«rffes ej> 
n uestca-eleclara c i 6n^€r" f so 
breimpriijiira^-gnlos vajores 

ortados poj^e+Tcfentifica^ 
de textura indutdoT Co 
mo podetsTfnaginar, esto'es 
de unajnrjp0rt5ncia cap. 
'a que conPpV^adjunta, 
'mpletisimajibfena de 
J^xjwras-derocas, metales, 
maderas, cielos, cristales... 
En las siguientes lineas, por 
ejemplo, se declara una 
nueva textura de madera 
que es igual a la predefinida 
T_Wood17, pero cambian- 
do el valor de turbulencia: 

#declare T1 7 = texture 

{T_Wood17 





Podemos pu 
utilizar / "tal / dual" Ms textures 7 
de la libreria (simplemente 
empleando la sentencia #in- 
cjdde cx5n los/archiws co- 
rrespondientes) o biepr po- 
demos incluirlas para usarJas 
erMa dedaradpn de/fuesy 
tros/p'ropios materiales 'o 
podemos.< 






-cfue puede creafSe una tra- 
■vpatxppr^la explicacion 
detaUtfcia de las sentencias 

''de texturas y el estudio de 
su aplicacion para crear ma- 
teriales complejos rebasa el 
proposito de este libra. Por 
tanto recomiendo a los 
pov-novatos que, al menos 
de momenta, se limiten a 
emplear las texturas prede- 
finidas o bitmaps propios. 
No obstante lo que ya he- 
mos visto aqui sera sufiente 
para las escenas de prueba. 





Transformaciones 
espaciales 

Otro aspecto basico en el di- 

io die \osbbjeps es'el u^o 

le transformaciones espacia- 

es./Uamamos'asi a.fas opera-/ 

cibnes/que p'uecjen efectuar- 

se sobre los objetos para 

alterar su' poslcior/espfldal, 

,sus dimeralone/o si/orien- 

tacion. POV dispone de tres 
/ / 
transformaciones: la 

la e-scalacion y la 
primera opera- 
ciprt carnbia la colocacion de 
os objetos, la segunda altera 
laydimensiones de los obje- 
tos y la tercera sirve cars 
la orientacioffdglgsabj 
Los tres tipos de transforma- 
ciones necesitan de un vec- 
tor que especifique los valo- 
res necesarios para los ejes X, 
y y Z. Con ello, el formato de 
estas operaciones es: 
rotate <x,y,z> 
scale <x,y,z> 
translate <x,y,z> 
Podemos utilizar tantas 
operaciones de transforma- 
cion como queramos para 
un mismo objeto y emplear, 
asimismo, el orden que que- 
ramos para ellas. Por ejem- 
plo, es perfectamente valido 
escribin 

sphere { <0, 0, 0>, 3 
texture {T1 7} 
scale <1 ,2,1 > 
rotate <0,0,45> 
translate <-5, 20, 1 > 
rotate <35,0,0> 

} 
Como veremos, las trans- 
formaciones pueden aplicar- 
se al objeto completo, o sea: 
a su forma y textura o bien 
podemos hacer que afecten 
solo a la geometria o a la tex- 



tura del objeto. En el ejem- 
lo anterior, las operaciones 
ifectan a ambas cosas. 

Traslacion 

Esta es la mas simple de las 
transformaciones. Losvalores 
en cada eje, en el vector, es- 
pecifican el numero de uni- 
dades en que el objeto se 
desplazara a lo largo de los 
ejes de coordenadas. Estos 
valores no son absolutos, si- 
no relativos a la ultima posi- 
cion del objeto. jRecordar 
este detalle es vital! Por ejem- 
plo, en el ejemplo siguiente, 
ica- 
ba°gfT Ia*po§fcTof1 , <2^ 
sinoen la <3,15,-2>. 

sphere{<5,5,5>,2 pigment 
{Red}translate<-2,10,-7>} 

Escalation 

Con scale podemos alterar 
las dimensiones de los ob- 
jetos usando factores de es- 
calado como parametros 
para los ejes. Si los factores 
tienen el mismo valor en los 
tres ejes, las dimensiones 
del objeto afectado aumen- 
taran o disminuiran pero la 
forma del objeto quedara 
igual. El factor de escala 
multiplica las dimensiones 
del objeto a lo largo del eje 
correspondiente. Asi... 

sphere{<0,0,0>,2 pig- 
ment {Red} scale<.5,2,1> } 
...la esfera del ejemplo se 
estrechara en el eje X, que- 
dando con una longitud de 
2 unidades. En el eje X en 
cambio, la esfera se alargara 
hasta las 8 unidades de lon- 
gitud y la longitud en el eje 
Z quedara igual, ya que he- 
mos multiplicado su valor 
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orisinal por 1 unidad. Es 
muy importante tener en 
cuenta que los cambios de 
escala son relativos al ulti- 
mo tamano obtenido (se 
puede haber empleado 
mas de una sentencia scale) 
y tambien a la posicion del 
objeto. Por ejemplo, en el 
siguientecaso... 

sphere{<0,5,0>,2 pig- 
ment {Red} scale<. 5,2,1 > } 
...comenzamos con una es- 
fera centrada en X y Z, cuyo 
centra en el eje y es la posi- 
cion 5. Como la forma de la 
esfera se multiplica por 2 en 
este ultimo eje, el nuevo 
centro se desplazara a la 
posicion 10, con lo que ha- 
bra un desplazamiento del 

bjeto en este eje. En los 
'ejiS^sstantes, la esfera no 
sufn?8-^W5brescon respec- 
to a I ejerr1pk>jltei4©j^ya 
que el objeto esta 
trado en dichos ejes. Por 
esta razon, es practicamen- 
te obligatorio efectuar la 
"construccion" de objetos 
complicados fijando su 
punto central (de los tres 
ejes) en la posicion 
<0,0,0>. Por ello, si lo que 
queriamos era que la esfera 
del primer ejemplo queda- 
ra centrada en <0,5,0>, de- 
beremos escribin 

sphere{<0,0,0>,2 pig- 
ment {Red} scale<.5,2,1> 
translate<0,5,0>} 



Rotacion 

La instruccion rotate girara 
el objeto el numero de gra- 
dos que se indique en los 
parametros para X, y y Z. El 
giro se efectua siempre con 
respecto al centro de coor- 



denadas. Esto quiere decir 
que si el objeto esta centra- 
do en dicho centro, rotara 
sobre si mismo. En cambio 
si se halla a cierta distancia 
del centro parecera descri- 
be una orbita en torno a la 
posicion <0,0,0>. Por esta 
razon, si por ejemplo que- 
remos que un objeto cen- 
trado en la posicion <21,- 
56,1 7> gire 45 grados en el 
eje X sin alterar su posicion, 
deberemosescribir... 
translate<-21 ,56,-1 7> 
rotate<45,0,0> 
translate<21,-56,17> 
La primera traslacion po- 
siciona el objeto en el cen- 
tro de coordenadas, la si- 
guiente rota el objeto los 
grados deseados y la terce- 
ra lo devuelve a su posicion 
original (pero ya rotado). 
Notese que realmente no es 




Los valores dados a rotate 
pueden ser positivos o ne- 
gatives, lo que afectara al 
sentido del giro. Para recor- 
dar el sentido que tendra 
una rotacion positiva para 
cada eje, existe la siguiente 
regla. Mentalmente haremos 
el gesto de OK con la mano 
izquierda. Seguidamente, 
sin alterar el gesto, orienta- 
remos la mano de forma 
que el pulgar apunte en el 
sentido positivo del eje cu- 
yo sentido de giro intenta- 
mos recordar. El sentido 
positivo del giro sera el mis- 
mo que siguen nuestros 4 
dedos cerrados (y el nega- 
tivo el opuesto, por su- 
puesto). Por esta razon el 
sistema de coordenadas de 



POV es llamado "de mano 
izquierda". ya solo queda 
advertir que el orden de las 
rotaciones influira en el re/ 
sultado final. En la insjj^Ci- 
cion:rotate<45,10,20>. 

El objeto rotaria primero 
45 grados enX, luego 10 en 
el y y finalmente 20 en el Z. 
Si deseamos que el orden 
de las rotaciones sea distin- 
to habremos de usar dos o 
tres sentencias de rotacion. 

Operaciones CSG 
entre objetos 

Nuestras escenas no po- 
drian ser demasiado visto- 
sas si se limitaran a mostrar 
objetos como cubos y es- 
feras con distintos tamanos, 
colores y posiciones. 

Afortunadamente, POV' 
cuenta con un factoradioo- 
nal qye-es^iKpl^zfl angular 
en la que reposa la potencia 
del diseno de objetos: las 
operaciones CSG. 

Estas operaciones, tam- 
bien llamadas booleanas, 
se emplean para crear nue- 
vos objetos realizando su- 
mas y restas con los volu- 
menes espaciales de dos o 
mas objetos. Supongamos 





iue tenemos dos objetos; 
una esfera y un cubo colo- 
cados de tal manera que el 
cubo (de mayor tamano) se 
superpone al volumen es- 
pacial ocupado por la mi- 
tad infeKor df la esfera 
(comparte^ cfcho espa- 
cio). Si restamos el cubo a 
la esfera, el resultado sera 
una semiesfera. Si la resta se 
efectua sobre el cubo el re- 
sultado sera un cubo con 
un espacio esferico (recor- 
tado en su interior). 

Las transformaciones es- 
paciales estudiadas antes 
pueden aplicarse tambien a 
los objetos CSG. Pero lo 
mas importante es que es- 
tos objetos pueden, a su 
vez, ser usados en nuevas 
^operaciones de CSG para 
producir nuevos objetos. 

De esto se deduce que, 
partiendo de primitivas 
muy sencillas (cajas, esfe- 
ras, cilindros, etc.), pode- 
mos acabar obteniendo 
modelos de apariencia muy 
compleja. Este modo de 
trabajo tambien es llamado 
"Geometria de construc- 
cion de solidos" porque 
solo puede operar con ob- 
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La esfera roja 
alrededor del eje y 
hasta superponerse 
a la casa, sobre la 
que efectuara una 
resta CSG. 



jetos que tengan un volu- 
men interior definido. Las 
cajas y las esferas, por 
ejemplo, lo tienen, al igual 
que las primitivas de cilin- 
dros y conos -siempre que 
estas no empleen la pala- 
bra "open" (ya que entran- 
ces los objetos estarian 
abiertos y sin grosor en las 
paredes). 

POV dispone de 4 ope- 
raciones de CSG: union, 
difference, intersection y 
merge. 

Union CSG 

Con esta operacion, dos o 
mas objetos se unen para 
formar uno solo. Para crear 
una union bastara con en- 
globar dos o mas objetos 



dentro de las Naves de la 
palabra union. 
Por ejemplo: 
union{ 

box{<-5,-4,-10>, 
<5,4,10>} 

sphere{<0,0,0>,4 
translated 0,15,0>) 
pigment(Red) 
rotate <30,0,0> 

1 

En esta union, la opera- 
cion de traslacion solo 
afecta a la esfera pero la ro- 
tacion afecta a ambas for- 
mas y el pigmento se usa 
tambien para las dos. 

Tambien podemos crear 
un identificador para esta 
union y emplearla en mas 
de un sitio (otra vez decla- 
re). La mayoria de las veces 
la union se emplea para 
crear un unico objeto sobre 
el que se operan nuevas 
operaciones CSG. 

Difference CSG 

La palabra difference equi- 
vale a la resta de objetos. 
En esta operacion la resta se 
efectuara sobre el primer 
objeto citado y los siguien- 
tes se emplearan como ob- 
jetos de resta. Veamos un 
ejemplo: 
difference! 

sphere{<0,0,0>,4 ) 
box{<-1 0,1 .50,-1 0>, 
<10,10,10>) 

box{<-1 0,1. 50,-1 0>, 
<10,10,10> rotate 

<180,0,0>) 

rotate <0,0,90> 

pigment{Red} 

} 

Aquf el resultado sera una 
especie de llanta: la esfera 
de la que se restan las dos 



cajas. Notese como ni tan 
siquiera nos molestamos en 
calcular los extremos de la 
caja inferior. 

Simplemente creamos la 
misma caja y la hacemos 
rotar 180 grados en X para 
que quede a igual distan- 
cia en el lado negativo del 
ejeY 

Finalmente, la segunda 
rotacion afecta al objeto 
creado y lo gira para que la 
llanta pueda "rodar". 

Intersection CSG 

En la interseccion, el obje- 
to resultante sera el forma- 
do por los volumenes es- 
paciales que compartan 
todos los objetos usados 
en esta operacion. Las si- 
guientes lineas: 
intersection { 

sphere { <0, 0, 0>, 4 
translate <-2,0,0> } 

sphere { <0, 0, 0>, 4 
translate <2,0,0> } 

pigment { Red ] 

} 
...crean una especie de ba- 
lon de rugby creado con el 
volumen espacial que am- 
bas esferas compartian. 

Merge CSG 

Esta operacion funciona 
exactamente igual que 
union. 

La unica diferencia estri- 
ba en que las partes com- 
partidas de los objetos usa- 
dos con merge (fusion) 
desaparecen. 

Esto es util cuando se es- 
tan aplicando texturas no 
opacas (cristal, hielo, etc.), 
donde puedan verse partes 
internas. 
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Planificar un proyecto 



Al idear un proyecto 
para crear escenas o 
animaciones es preciso 
tener en cuenta una 
serie de factores que 
influiran en el buen 
desarrollo del mismo. 
En primer lusar, hay 
que tener en cuenta la 
escena en si; que 
objetos van a 
componerla, como 
vamos a construirlos, 
las texturas que se 
emplearan... 

A partir de esto, hay que in- 
tent* adivinar si la realiza- 
cion del proyecto es facti- 
ble, teniendo en cuenta el 
hardware y el tiempo de 
que se dispone. Otro factor 
adicional que puede aca- 
bar siendo un verdadero 
problema para algunas per- 
sonas es el gusto por el de- 
talle. Uno puede comenzar 
con una idea relativamente 
sencilla como la de un Cas- 
tillo compuesto por 2 o 3 
torres sencillas, un par de 
muros y un montecillo don- 
de colocarlo todo. Sin em- 
bargo, conforme se van cre- 
ando objetos, uno puede 
acabar entusiasmandose de- 
masiado, y acabar intentan- 
do crear una autentica ciuda- 
dela amurallada, con 
docenas de casas distintas y 
un enorme Castillo de fondo. 
Esto fue lo que sucedio 
en el caso de Castlib. En un 
momento dado, pensamos 



colocar casas alrededor del 
Castillo para darle mayor 
realismo. Estas casas tan so- 
lo servirian de fondo para la 
estructura principal (el Cas- 
tillo) y nunca se verian de 
cerca, por lo que no preci- 
sarian demasiado detalle. El 
caso es que, sin saber co- 
mo, al final las casas co- 
menzaron a recargarse con 
detallitos, variaciones, tex- 
turas propias, etc. El tiempo 
se acababa y las estructuras 
del castillo... jPorel rayotra- 
zado con calidad 9! No es- 
taban listas. Pero, en fin, de 
todos modos town.inc (fi- 
chero extraido del proyec- 
to original) nos servira para 
ilustrar los pormenores de 
la creacion de un proyecto 
y algunas nuevas caracteris- 
ticas y sentencias de POV 
3.0. Antes de comenzar, no 
obstante, queremos dejar 
claro que, en parte, lo que 
se dice en este capitulo es 
bastante subjetivo. Vamos a 
estudiar el desarrollo de un 
proyecto, pero siempre hay 
mas de una manera de ha- 
cer las cosas y otros usuarios 
de POV pueden emplear 
metodos distintos y no ne- 
cesariamente inferiores. 



Evolucion de un 
proyecto 

A pesar de su antiguedad, 
la idea inicial de Castlib no 
ha cambiado gran cosa. Di- 
cha idea consistia en dise- 
har unas cuantas estructuras 



sencillas que se combina- 
rfan entre si de diversos 
modos para crear otras algo 
mas compiejas, las cuales, a 
su vez, tambien podrian 
combinarse para crear cons- 
trucciones de complejidad 
aun mayor. De este modo, 
se esperaba que las escenas 
aparentasen una compleji- 
dad algo elevada a cambio 
de un esfuerzo de modela- 
do relativamente bajo. 

Lo que si ha experimenta- 
do cambios en Castlib ha 
sido la forma de construir 
los objetos basicos. Al 
principio, por ejemplo, las 
torres circulares se cons- 
truian utilizando un enorme 
cilindro como cuerpo. Este 
cilindro podia tener 10, 20, 
30 o incluso mas metros vir- 
tuales. A este objeto se le 
practicaban restas CSG (dif- 
ferences) para las ventanas, 
se le ahadian (union) mar- 
cos para estas, aspilleras 
para las almenas, etc. Natu- 
ralmente, cuanto mayor fue- 




Este es el 
panel basico 
con el que se 
construyen los 
demas. 
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se la torre a crear, mayor era 
el numero de restas boolea- 
nas a efectuar sobre el cilin- 
dro y mayor tambien el nu- 
mero de objetos a anadir. 

Mientraj-tas rorres fueron 
relativamente pequenas no 
hubo problemas pero muy 
pronto quedo patente una 
cosa: con torres s relativa- 
mente srandes, llenas de 
ventanas y-torrecitas adosa- 
das, el tiampo de genera- 
cion de laescena se dispa- 
raba. El proyecto no 
resultkba practice Por 
aquel aptonces (usando la 
version 2.0) no empleaba- 
mos boundins_slab. Al pa- 
sar a utilizar dichas figuras, 
los tiempos de generacion 
disminuyeron bastante, pe- 
ro pronto, cuando las esce- 
nas aumentaron un poco el 
nivel de detalle, se compro- 
bo que esto era insuficiente. 
El problema estaba relacio- 
nado con un sistema emple- 
ado por POV para acelerar 
los tiempos de calculo. 




Una de las cosas para las que 
POV requiere mas tiempo de 
calculo es la comprobacion 
-para cada rayo a trazar- de si 
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hay o no interseccion con las 
superficies de los objetos. 
Hay que pensar que por ca- 
da pixel se lanza un rayo que 
POV debe comprobar con 
todos los objetos de la esce- 
na. Ademas, se realizaran 
comprobaciones adicionales 
si hay que estudiar reflexio- 
nes, refracciones, etc. 

Como siempre, la mejor 
manera de ahorrar tiempo es 
hacer los menos calculos po- 
sibles y, para ello, POV em- 
plea el truco de los objetos 
bounding_slab. Los boun- 
dig_slab son objetos invisi- 
bles, normalmente esferas o 
cajas, que POV o el usuario 
definen alrededor de los ob- 
jetos complejos de la esce- 
na. Al usar esta tecnica, POV 
comprueba primero si el ra- 
yo intersecciona con alguna 
bounding_slab y de ser asi 
pasa a realizar los calculos de 
interseccion con el objeto 
englobado por la bounding 
detectada. Si no es asi, el ra- 
yo se desestima. Como es 
mucho mas rapido calcular 
ecciones para una caja 
que para los 
modelos'FSsafcipJejos que 
los objetos boungpigsuglen 
recubrir, el ahorro de 



se hace considerable. Otro 
detalle a tener en cuenta es 
que el bounding puede ha- 
cerse anidado. Es decir, pue- 
de haber un objeto boun- 
ding que recubra un modelo 
complejo y, a su vez, otros 
bounding interiores que re- 
cubriran partes del modelo. 

Naturalmente, para que es- 
ta tecnica resuite efectiva, es 
preciso que los objetos 
bounding sean objetos rapi- 
dos de calcular (cajas o esfe- 
ras) y que se ajusten lo mejor 
posible a los objetos que en- 
globan. Si el recubrimiento 
no es perfecto (o sea: si lo 
hacemos manualmente y cal- 
culamos mal las dimensiones 
o colocacion del objeto 
bounding), podemos perder 
tiempo de calculo o peor 
aun; hacer que queden invi- 
sibles partes de la escena. 

POV realiza un bounding 
automatico que se ha ido ha- 
ciendo mas y mas efectivo en 
cada nueva version, pero que 
aun no es perfecto, ya que el 
bounding automatico de 
POV no funciona bien en cier- 
tos casos, sobre todo en ob- 
jetos CSG con los que se han 
empleado objetos infinitos. 

Si el usuario desea colocar 
manualmente los objetos 
bounding, puede usar la sen- 
tencia boundedjoy, la cual 
tiene el siguiente formato: 

bounded_by { object_ 
bounding {...}} 

y en el manual de POV se 
cita el siguiente ejemplo... 

intersection { 

sphere { <0,0,0>, 2 } 

plane {<0,1,0>,0} 

plane {<1,0,0>,0} 

boundedjoy { sphere { 



<0,0,0>, 2 } } } 

Aqui el usuario ha definido 
una esfera situada en el ori- 
gen de coordenadas y con 
radio 2 para englobar este 
objeto CSG. 

Sin embargo, parece claro 
que, sobre todo a partir de la 
version 3.0, el uso de esta 
sentencia sera cada vez mas 
raro. Ello se debe en parte a 
que el bounding automatico 
de POV es, a menudo, mas 
preciso y mejor que el que 
puede especificar el usuario 
y ademas al hecho de que 
pocas veces se emplean ob- 
jetos infinitos en las opera- 
ciones CSG (salvo plane). 

Un truco sencillo 
para ganar tiempo 

Ahora que ya sabemos algo 
sobre una de las tecnicas 
empleadas por POV para ga- 
nar tiempo volvamos a nues- 
tro proyecto. Habiamos di- 
cho que en las escenas con 
torres grandes el tiempo de 
calculo se disparaba. Ello se 
debia, como ahora quedara 
claro, a que se estaba em- 
pleando un metodo erroneo. 
Cuando debamos crear es- 
tructuras que empleen un 
buen numero de operacio- 
nes CSG no debemos crear 
un unico objeto, sino un ob- 
jeto compuesto por otros. 

iQue quiere decir esto? En 
el ejemplo comentado antes, 
una torre era un unico objeto 
sobre el que se practicaban 
restas para las ventanas, puer- 
tas y portillas, y adiciones pa- 
ra los marcos correspondien- 
tes. El resultado podia 
presentar un aspecto bastan- 
te complejo pero no por ello 




dejaba de ser un unico obje 
to. Por esta razon, dentro del 
volumen espacial de la torreA 
POV debia emplear muchos 
testeos para saber si el rayo 
estaba tocando alsuno de 
los muchos marcos de venta- 
na o los agujeros de estas, 
etc. Asi, en el siguiente paso, 
procedimos a construir pisos 
que despues se apilarian uno 
encima de otro para montar 
las torres. De esta manera, al 
dividirse cada torre en varios 
pisos, POV paso a crear un 
objeto bounding para cada 
piso, aparte del empleado 
para la union de todos estos 
pisos, o sea: la torre. Con 
ello, al realizarse menos 
comprobaciones de inter- 
seccion con los detalles de la 
torre (marcos, agujeros, etc), 
el tiempo de generacion se 
redujo mucho. 

Variaciones 

El descubrimiento del pe- 
queno detalle citado mas 
arriba fue el factor principal 
que llevo a tirar al cubo la 
version anterior de Castlib y 
volver a comenzar el trabajo 
casi desde cero. Los disenos 
iniciales tambien fueron a pa- 
rar al cubo debido al descu- 
brimiento colateral de que, 
en unas estructuras que se 
montan a base de pisos, re- 
sulta posible combinar las 
construcciones de muchas 
maneras distintas, si las altu- 
rasy dimensiones coinciden. 

Sin embargo, a fin de apro- 
vechar a fondo la idea de la 
variacion, se necesitaba un 
numero minimo de pisos 
bastante ; diferentes entre si. 

■ebido a esto, y pensando 




Documentation 

Otro aspecto fundamental a 
la hora de crear una escena 
poblada con objetos no abs- 
tractos es la documentacion. 
Para las escenas que se dese- 
aban crear en este proyecto 
no se pretendia de ningun 
modo cefiirse a un estilo ar- 
quitectonico dado. Lo unico 
que se esperaba era que los 
modelos fuesen sencillos pe- 
ro resultones y por ello la do- 
cumentacion se tomo de 
fuentes tan diversas como los 
esplendidos escenarios del 
magnifico comic "Principe 
valiente" de Harol Foster (una 
obra de arte del genero), las 
cuidadas vinetas de "Perce- 
van", e incluso las delirantes 
paginas de "Groo", de Sergio 
Aragones. 

Tambien se consulto el ex- 
celente libro ilustrado,- "un 
castillo medieval", publicado 
aqui por Circulo de Lectores 
y se examinaron otras fuen- 
tes: Portofolios de artistas co- 
mo Rodney Matthews, vi- 



jxturas | 
<:abas medieVales 

ASahoraXje disewar las Tessas 
nedifevalesxdel Ttchero 
towa i nc s&tuvo eh-cuentat 
anteriol^nteex^cadoyun 
factor adiciohaj. el de^astex- 
turas que iban a emplearse> 
POV puede crear casi i 
quiertipodetextura imagina- 
ble empleando algoritmos,- 
madera, piedra, marmol, etc. 
(Por ello, tambien se llama 
"procedurales" a estas textu- 
ras). El codigo de POVgene- 
rara diversos resultados se- 
gun el tino con el que 
hayamos empleado las sen- 
tencias de texturas que con- 
trolan a estos algoritmos. Los 
materiales creados de este 



gefKbitrriaps) qufe-se pegaT>^ 
:S. Sia^ 

li- 
c&qo uns. pov-textura le 
fectLteflpos uTKmordiscc 
CSCHdiffereTice), no teT 

s quefseepcupafi 
aparien 
didai^Esta : 

la texti 
lalmertt&ajobjetor 

desdecefojjna bue- 
etitmica puec 
;equenr~bastante tiempc 
tiem^s<Jel que aveees-QCi 
e. AroftDflacJamente, 
ui se di =>ados circuns- 
tanciasT~ta~pnmera quel 
:3rpQrauna buen 
xturas prScedurales. Del 
f ichero wcKDetejncjoor ejem- 
plo, se tomo la textura c 
dera empleada en diversos 
sitios. Otro detalle que aho- 
rro mucho tiempo fue la ob- 
tencion de dos pequehos y 
bonitos bitmaps de piedras 
de muros. Hecho esto, solo 
restaba ver como disehar las 
casas, a fin de aplicarles uno 
de estos bitmaps. 
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Esto es lo que 
sucederia con rotate 
zx45 dentro de la 
sentencia de la 
textura. 



i instmccioniiriage rrfap < 

}lea para indicar a BOV 

queJeS colgzs que^se vam 

gplicaradore up'objejer'cla- 

forrespe>hden a^tos de> 
fichefo"bitma 

figh^fo puede estar en 

f^tga ogrfotros formatos 
mepesconocidos y tener 
"cualquier resolucion razona- 
ble. El formato para usar esta 
sentencia es: pisment { ima- 
ge_map{ formato "filename" 
modificadores } } 

En "formato" pondremos la 
palabra correspondiente al 
tipo de archivo bitmap que 
vamos a usar,- sif, tsa, png u 
otros. A esto sigue, entreco- 
millado, el nombre del archi- 
vo, el cual sera buscado por 
POV en el directorio en curso 




y/en los especif/cados por la 
rde/i de/inea/de coma?idos/ 
L. En cu^nto^ lo^mo<; 
d£Jres/son/sen1£nci^s qjde 
fect/n al/nodb, paJsicion y 
onafitacion can qi/e se/apli; 

el b/tmac/sobfe el ofojete 

Di/ha aplicafcior/pu^cle 
:arse de/varia/mar/ 

ra )<evarLa a cabo hay que 
:{2brda/queXin bitmap es 
omc/Una tela con la que de- 
bemos envolver, de la mane- 
a apropiada, el objeto. Por 
defecto/ta textura se proyec- 
:a en/el piano formado por 
losses X e X en el sentido -Z 
(entrando en la pantalla, se- 
gun el ejemplo del princi- 
pio). De no ordenar otra co- 
sa, la textura se aplicara en el 
area rectangular delimitada 
por las coordenadas (0,0) a 
(1,1). Este area de aplicacion 
puede trasladarse, rotarse o 
escalarse sobre el piano de 
aplicacion (que por defecto 
es el formado por los ejes X 
e Y) utilizando las mismas 
sentencias usadas para ope- 
rar con los objetos (o sea 
translate, rotate y scale). 

En caso de que el tamano 
del area de aplicacion, una 
vez transformada o no, resul- 
te insuficiente para cubrir al 
objeto, la trama del bitmap 
se repetira sobre este tantas 
veces como sea necesario, 
hasta que toda la superficie 
quede "pintada". POV dis- 
pone del modificador 
mapjype para permitirnos 
cambiar el tipo de aplicacion 
del bitmap. Mapjype va se- 
guida de un valor con el que 
indicaremos este detalle,- 
es el valor por defecto y el 
que corresponde a una apli- 



cacion plana, 1 realiza un 
oiapeado esferico sobre el 
sbjeto, 2 efectua un mapea- 
/do cilindrico y 5 un mapea- 
do toroidal (para objetos 
con forma de donut). La for- 
ma del mapeado afectara a la 
apariencia del objeto. 

Diseno elegido 

Es facil imaginar que las casas 
que ilustran estas paginas 
pueden modelarse de distin- 
tas formas. Se podria, por 
ejemplo, haber creado cajas 
de diferentes tamanos, y ha- 
ber aplicado el bitmap a ca- 
da pared desplazando y ro- 
tando el piano de aplicacion 
del mismo. 

Este sistema, en concreto, 
fue considerado y finalmen- 
te desechado por parecer 
poco flexible y demasiado 
trabajoso. Habia muchas par- 
tes cuya escritura habria de 
repetirse y paredes que exis- 
tirian pero que no se verian, 
con la consiguiente perdida 
de tiempo en calculos inuti- 
les. En lugar de esto, se opto 
por otro sistema bastante ra- 
dical. Se decidio crear una 
coleccion de paredes o pa- 
neles diferentes que se em- 
plearian para crear todas las 
casas. Un panel podia ser un 
muro con vigas cruzadas, 
una pared con puertas oven- 
tanas, etc. De este modo, un 
monton de casas diferentes 
podia definirse con poco 
esfuerzo definiendo los mo- 
delos como uniones de pa- 
neles y otros objetos. Con 
esta filosofia una casa senci- 
lla es, simplemente, 4 pare- 
des a las que se les ha pues- 
to un techo. 
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Un poblado 
medieval 



En town.inc hay 
declaradas cerca de 50 
estructuras utilizables 
de diversa 
complejidad. 

Aunque se ha intentado se- 
guir un cierto orden, obser- 
vareis que en las casas de 
distintos tamafios se em- 
plean metodos diferentes. 
Esto se ha hecho asf en par- 
te por capricho, para averi- 
guar que metodo era el mas 
practico, en parte por inten- 
tar ilustrar diferentes meto- 
dos para llegar a resultados 
similares y en parte porque 
un sistema que funciona 
bien en un tipo de objetos 
no tiene porque ser igual- 
mente valido para otros. 

La primera pared 

Ante todo era preciso es- 
coger un sistema de medi- 
das para construir los obje- 
tos y calcular distancias. En 
Castlib, por definicion, 10 
unidades de POV equivalen 
a un metro. Otra norma ele- 
gida fue que el suelo, don- 
de se colocarian los esce- 
narios, estaria formado por 
el piano X-Z, a la altura y=0 
del origen de coordenadas. 
Definidas estas reglas, el 
primer objeto creado fue 
una sencilla caja que repre- 
sentaria un trozo de pared 



de 5x5 metros (50 pov-uni- 
dades por cada lado). A 
este primer objeto, al que 
luego se le ahadieron vigas 
en los lados, se le llamo pa- 
nelb (por panel basico). 
Como el bitmap se aplica 
por defecto en el piano X- 
X el panel fue colocado pa- 
ralelamente a dicho piano. 

Ademas, como se cons- 
truirfan nuevos paneles to- 
mando el basico como ba- 
se y como dichos nuevos 
paneles tendrian, a veces, 
que ser rotados para colo- 
car las paredes laterales de 
las casas, panelb se definio 
centrado en el eje Z. Como 
las paredes son todas verti- 
cales (paralelas al piano X- 
y) no era preciso centrar el 
panel inicial en X por lo que 
se coloco esta primera pa- 
red justo encima del suelo. 

A esta pared inicial se le 
coloco el bitmap. Dicho 
bitmap, que no ha sido in- 
cluido con los fuentes de 
Castlib por no tener dere- 
chos de distribucion sobre 
el mismo, es una imagen de 
una trama de rocas. Esta 
imagen es "tileable", como 
suelen decir los grafistas, o 
sea que las rocas de un la- 
do encajan con las del ex- 
tremo opuesto del bitmap. 
Esta caracteristica es suma- 
mente util por dos razones: 



la primera porque, aunque 
se aprecie repeticion, no se 
notaran fallos al aplicarse 
repetidamente la textura y 
la segunda porque no ha- 
bra que preocuparse de la 
posicion en que se colo- 
que esta sobre el muro. La 
pongamos como la ponga- 
mos encajara. 

De lo que si habia que 
preocuparse era del tama- 
ho relativo que tendrian las 
rocas del bitmap sobre el 
muro. Como se dijo antes, 
el piano de aplicacion de la 
textura se extiende por de- 
fecto sobre un area cuadra- 
da de 1 unidad de largo. 
Esto significa que, como el 
muro tiene 50, la imagen se 
repetiria 50 veces por cada 
lado. O sea que no veria- 
mos ladrillos sino tan solo 
un feo punteado. Para re- 
mediar esto bastaba con 




Aqui puede verse 
como un distinto 
vaor de seed sirve 
para generar calles 
diferente. 
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escalai^el-iSltmap^fixamine 
mos la dgdaraaon djsP&b 
> panelb: 

rtafe panelfc>=union{ 
bo&{«-§5^0>,<25£(£5> 
p i 3 m e nt^JflTcTg e_m aplfiga 
3ie3ra2.tga^ 

trarisJate< 
3>3Gdte^14,14,1^ 
:{viga 
ranslate^0750^>) 
obj ectjyiga^otate 
^O&afista1e<a2 / 0>} 

objectfviga translate 
<-25,25,0>} 

objectfyiga translate 
<25,25,0>) } 

Como vemos, panelb se 
ha declarado como una 
union de objetos. El primer 
componente de la union es 
la caja que hara las veces 
de muro y los 4 siguientes 
son las 4 vigas de madera 
que bordean el muro. (Las 
vigas son tan solo cajas alar- 
gadas con texturas de ma- 
dera). Despues de la sen- 
tencia image_map siguen 
dos operaciones de trans- 
formacion. La primera, 
translate, no tiene demasia- 
da importancia y sirve tan 
solo para que, al centrar el 
area de aplicacion de la 
textura en <0,0,0>, la apli- 



Mas tipos de muros 

Una vez definido el panel 
basico, podemos crear un 
nuevo panel basandonos en 
el ya creado. Por ejemplo: 

// con puerta a la izq. y 
ventanita tipo 1 a la der. 
#declare panell 1 =union{ 
difference! 
object{panelb} 
object{recpuer1 
translate <-14,0,0>) 

objectjrecvenl 
translate <1 2,25,-1 >) 

} 

object{puerta transla- 
ted 4,0,1 >} 

object{marcove1 
translate <12,25,2>} 

} 
...se declara el panel nume- 
ro 11 . Examinemos la decla- 



: Pa/iel1/l se/ define 
omfi una unibn eyn la/iualy 
el primer elamer/to es un/ 
dj/erer/cia./EI ojojeta de/la 
festa/es ufia copia/de j6i 
nelp que errvpleamos/parc 
c/ear l/forraa basicaae ps 
'nelT/T. 0/Sea:/fes r#stas/b!e 
Ipsn objetos tecpuerl yrec- 
en no se CTecti/an szibre el 
a/felb esrigioal, sipfo sobre 

coprta de/mis/ho que to- 
anen 1 , tain pronto co- 
?4ial la/la sentencia ob- 
eottpaneib}. Esta copia se 
ncu^ntra en la misma posi- 
ci0n y orientacion espacia- 
es y hereda las mismas pro- 
piedades (tamano, materia- 
les, etc.) que el original. Los 
objetos de resta empleados 
se hallan definidos al princi- 
pio de town.inc y son agu- 
jeros para crear una puerta y 
una ventana. Estos agujeros 
son trasladados -ya que 
tambien estaban creados 
de forma centrada en el ori- 
gen- a las posiciones donde 
iran los marcos de la puerta 
y la ventana. Los objetos- 
marco son los otros tres 
componentes de la union. 

(Notese que los tres obje- 
tos situados dentro de las 
Haves de la operacion diffe- 
rence NO son parte de la 
union. El resultado de la 
operacion de diferencia, en 
cambio, es un objeto del 
cual SI podemos decir que 
es un elemento de la union). 

El nuevo objeto declara- 
do; panell 1, puede a su 
vez, ser empleado en la de- 
claracion de nuevos obje- 
tos (esta potente caracteris- 
tica de POV nos ahorrara 
muchas lineas de texto). Po- 



demos comprobar este de- 
talle fijandonos en la decla- 
/acion del panell 2. 

// con puerta a la izq., 
ventanita tipo 1 a la der. y 
viga diagonal 

#declare panell 2=union{ 
object{panel11} 
objectfviga scale 
<1 .5,1 .33,1 > rotate z*45 
translate <0,25,-0.2>} 

} 

Con tan solo tres lineas de- 
claramos el panell 2. En di- 
cha declaracion se crea un 
nuevo objeto que es la union 
entre una copia del panell 1 
y una viga cruzada diagonal- 
mente sobre el panel. 

Trucos 

Una vez definidos los 15 pa- 
neles que forman nuestra co- 
leccion, y con los que se han 
definido todas las casas de 
town.inc, es el momento de 
crear nuestra primera casa. 
Antes los pov-novatos debe- 
rian tomar nota de algunos 
trucos sencillos: 

1 ) Casi siempre, el objeto 
debe construirse centrado 
en el origen de coordenadas. 

2) Recordad que si un ob- 
jeto esta situado a cierta dis- 
tancia del centra de coorde- 
nadas es muy facil crear un 
nuevo objeto -identico- en 
una posicion comprendida 
dentro del circulo que forma 
el radio desde la posicion 
del objeto original hasta el 
origen de coordenadas. Este 
truco se empleo, por ejem- 
plo para colocar las aspilleras 
de las torres circulares (ver 
PCmania 47). Primera se de- 
finia una aspillera a x distan- 
cia del origen y luego las de- 
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mas se definian haciendo 
una copia rotada x grados 
con respecto a la original. 

3) Es muy util colocar ca- 
maras en los ejes que apun- 
ten al origen de coordena- 
das, donde hemos colocado 
al objeto en construccion, de 
este modo tendremos las vis- 
tas: frontal, lateral, superior, 
etc. Si la camara apunta al 
centro del objeto sera mas 
facil detectar imperfecciones 
en la simetria y otros detalles. 

4) Tambien es muy util de- 
finir un piano con checker 
como suelo donde se colo- 
caran los objetos que vaya- 
mos a construir. De este mo- 
do, podremos ver si las 
medidas y distancias entre 
objetos son correctas. En 
Castlibel metro equivale a 10 
unidades por tanto debere- 
mos escalar el checker por 
10 para que cada cuadro 
equivalga a uno de nuestros 
metros virtuales. 

Levantar casas 

Se han empleado leves varia- 
ciones en la idea basica para 
crear los distintos tipos de 
casas. Sin embargo, el meto- 
do ha sido siempre el mis- 
mo: definir uniones de obje- 
tos-muro, colocados y 
rotados convenientemente. 
Normalmente, cuando la ca- 
sa iba a tener mas de un piso, 
se procedia a declarar pisos 
y luego la casa se definia co- 
mo una union de pisos diver- 
sos. El segundo piso se colo- 
caba (translate <0,50,0>) a 5 
metros de altura 00 sobre el 
primero, el siguiente a 10 
metros, etc. Naturalmente, 
tambien se han empleado 



otros objetos,- los marcos pa- 
ra ventanas y puertas, por 
ejemplo, se crearon em- 
pleando la sentencia Prism 
descrita en PCmania 47. Las 
buhardillas son casas -que 
emplean panelb en todos 
sus muros- a las que se han 
aplicado operaciones de es- 
calado y sobre las que se ha 
puesto una ventana sin esca- 
lar. Los tejados... Lo impor- 
tante es que para usar 
town.inc, el usuario solo ten- 
dra que colocar la necesaria 
sentencia #include en su fi- 
chero, y citar desde alii los 
objetos cuyo nombre em- 
pieza por "casa". Las casas 
de 1 a 1 tienen 1 metros 
de altura, las de 20 a 29 tie- 
nen un piso extra, yasf suce- 
sivamente. Si el lector exami- 
na town.inc observara 
ocasionalmente identificado- 
res con nombres tales como 
casa32a, casa34c, etc. Estos 
nombres indican que el ob- 
jeto es una variacion del di- 
seho original. 

Levantar calles 

Una vez listos para crear el 
pueblo surge el problema de 
que metodo emplear. Pode- 
mos colocar las casas a ma- 
no pacientemente pero ha- 
bra que hacer muchas 
pruebas, ya que seguramen- 
te cometeremos muchos 
errores en la creacion de las 
calles,- casas que se superpo- 
nen unas a otras, excesiva 
distancia entre las mismas, 
etc. La verdad es que el me- 
todo mas sencillo se basa en 
emplear algunas de las nue- 
vas sentencias de POV 3.0. 
No vamos a describir ahora 



estas sentencias (ya lo co- 
mentamos en PCmania 47), 
pero si diremos que aquellos 
que tengan nociones de pro- 
gramacion no tendran ningun 
problema con ellas. En el fi- 
chero generador de las pov- 
ciudades se emplen dos bu- 
cles #while para crear una 
rejilla de casas. La colocacion 
de una casa u otra se decide 
usando el generador de nu- 
meros pseudoaleatorios que 
incorpora POV (funciones 
RandO y SeedO) y la funcion 
int(). Tambien se emplean 
sentencias Switch y sus co- 
rrespond ientes #case. Todas 
estas sentencias tienen un 
uso casi identico al que po- 
driamos esperar en un len- 
guaje de programacion. Hay 
que subrayar un detalle muy 
atractivo; cambiando el valor 
dado como semilla a la fun- 
cion seed(), los valores sumi- 
nistrados por Rand() cambia- 
ran y el resultado sera un 
pueblo totalmente diferente. 

Ciudades 

Podriamos imaginar que las 
ciudades que podemos 
crear pueden tener cientos, o 
miles de edificios pero esto 



no es posible. Aunque los fi- 
cheros escenicos ocupan 
muy poca memoria, el mo- 
delo interno que construye 
POV para generar las escenas 
si necesita bastante RAM. Os 
aconsejamos que no creeis 
declaraciones de bucles whi- 
le de objetos, ya que enton- 
ces se requerira bastante mas 
memoria al necesitarse espa- 
cio para el modelo declara- 
do y la copia invocada. Des- 
conocemos los detalles 
exactos acerca del modo en 
que POV gasta memoria. Tan 
solo podemos repetir lo que 
hemos visto en las pruebas. 

En cuanto a las fotos, no 
hay mucho que destacar. Ba- 
sicamente solo se usaron dos 
camaras para todas ellas cam- 
biandose casi siempre, en 
cambio, el valor de seed y el 
numero de columnas y filas. 
Notad el fallo cometido en 
una de las fotos. La rutina ex- 
tiende la ciudad desde un 
punto alejado de la posicion 
<0,0> de X y Z. Como en di- 
cha foto se utilizo una esfera 
para simularel mundo, y solo 
tenia 100.000 unidades de ra- 
dio, el resultado fue que las 
casas parecen flotaren el aire. 
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